Memory test system and test method

Abstract

The application provides a memory test system and a test method, the test system is used for selectively running in a pure hardware test mode or a system level test mode; wherein, in the pure hardware test mode, a third-party storage medium independent of the memory is started to load a test system image and a customized kernel; after the customized kernel is started, a test driving module is loaded and a test node is created, the test driving module is used for shielding a system default power management mechanism and / or a retry mechanism, and the test node is used for communicating with a host computer to receive a test instruction for testing the memory issued by the host computer and returning a test state and test data of the memory. The independent test system is loaded from the third-party storage medium independent of the memory, instead of starting the Android system from within the memory, so that it is unnecessary to write the Android system information in the memory, and the problem that the test coverage is limited due to that the Android system information occupies part of the storage area in the memory is avoided.

Description

Technical Field

[0001] This application relates to the field of memory control, and in particular to a memory testing system and testing method. Background Technology

[0002] UFS storage, as a high-performance storage device, is widely used in platforms such as mobile phones and in-vehicle systems. Traditional testing schemes for UFS storage often rely on the file system interface of the host operating system (such as Android / Linux systems), which suffers from incomplete test coverage, operational limitations, and difficulty in implementing anomaly testing. In addition, system-level retry, power-saving, and frequency reduction mechanisms can interfere with testing behavior, resulting in test results that do not meet expectations, and it is difficult to preserve the fault scene. Summary of the Invention

[0003] In view of this, this application provides a memory testing system and testing method to solve or partially solve the above problems.

[0004] In a first aspect, this application provides a memory testing system, including a test platform and a host computer. The test platform is connected to the memory via an interface. The test platform is used to selectively run in a pure hardware test mode or a system-level test mode. In the pure hardware test mode, the test platform is used to boot from a third-party storage medium independent of the memory to load a test system image and a customized kernel to initialize the test platform. After the customized kernel boots, the test platform loads a test driver module and creates test nodes. The test driver module is used to shield the system's default power management mechanism and / or retry mechanism, and communicates with the host computer through the test nodes to receive test instructions for testing the memory issued by the host computer and return the memory's test status and test data to the host computer.

[0005] In a second aspect, this application provides a memory testing method applied to the memory testing system described in the first aspect. The method includes: receiving a test instruction for testing the memory; acquiring test data of the memory according to the test instruction; and returning the test data and the test status of the memory, wherein the memory is connected to the memory testing system.

[0006] This application provides a memory testing system and method. The testing system can selectively run in either a pure hardware testing mode or a system-level testing mode. In pure hardware testing mode, it boots from a third-party storage medium independent of the memory to load a test system image and a customized kernel. After the customized kernel boots, a test driver module is loaded and a test node is created. The test driver module masks the system's default power management and / or retry mechanisms and communicates with a host computer through the test node to receive test commands from the host computer for testing the memory and return the memory's test status and test data. By loading an independent test system from a third-party storage medium independent of the memory, rather than booting the Android system from within the memory, it avoids writing Android system information into the memory, thus preventing the limited test coverage caused by Android system information occupying a portion of the memory's storage area. Attached Figure Description

[0007] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, and these are all within the protection scope of this application.

[0008] Figure 1 A schematic diagram of an exemplary memory storage system according to an embodiment of this application is shown.

[0009] Figure 2 A schematic diagram of an exemplary memory controller according to an embodiment of this application is shown.

[0010] Figure 3 A schematic diagram of an exemplary memory management module according to an embodiment of this application is shown.

[0011] Figure 4 A schematic diagram of the system architecture of an exemplary memory testing platform according to an embodiment of this application is shown.

[0012] Figure 5 A schematic diagram of the internal mechanism of an exemplary UFS test driver module according to an embodiment of this application is shown.

[0013] Figure 6 A schematic diagram of the architecture of a power management module according to an embodiment of this application is shown.

[0014] Figure 7 A flowchart illustrating an exemplary memory testing method according to an embodiment of this application is shown.

[0015] Figure 8 A flowchart illustrating an exemplary memory testing method according to an embodiment of this application is shown.

[0016] Figure 9 A schematic diagram of the layout of an exemplary host computer GUI interface according to an embodiment of this application is shown. Detailed Implementation

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

[0018] It should be particularly noted that similar substitutions and modifications made to this application are obvious to those skilled in the art, and they are all considered to be included in this application. Those skilled in the art can obviously make modifications or appropriate alterations and combinations to the methods and applications described herein without departing from the content, spirit, and scope of this application to implement and apply the technology of this application. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0019] Figure 1 A schematic diagram of an exemplary memory storage system 100 according to an embodiment of this application is shown.

[0020] like Figure 1As shown, the memory storage system 100 includes a host system 102 and a storage device 104. The host system 102 can be any type of computer system, such as a laptop computer, desktop computer, smartphone, tablet computer, industrial computer, etc. The storage device 104 is used to store data from the host system 102. The storage device 104 may include a solid-state drive (SSD), universal flash storage (UFS), embedded multimedia card (eMMC), secure digital card (SD), USB flash drive, or other types of non-volatile storage devices. The host system 102 can be electrically connected to the storage device 104 via a Serial Advanced Technology Attachment (SATA) interface, Peripheral Component Interconnect Express (PCI Express), Universal Serial Bus (USB), or other types of connection interfaces. Therefore, host system 102 can store data to storage device 104 and / or read data from storage device 104.

[0021] Storage device 104 may include a connection interface 1041, a memory module 1042, and a memory controller 1043. The connection interface 1041 is used to connect storage device 104 to host system 102. Storage device 104 can communicate with host system 102 via connection interface 1041.

[0022] Memory module 1042 is used to store data. Memory module 1042 may include a non-volatile memory module. Memory module 1042 includes an array of memory cells. The memory cells in memory module 1042 store data in the form of voltage. In some embodiments, memory module 1042 may be a NAND flash memory module (NAND Flash).

[0023] Memory controller 1043 is connected to connection interface 1041 and memory module 1042. Memory controller 1043 can be used to control storage device 104; for example, memory controller 1043 can control connection interface 1041 and memory module 1042 for data access and data management. For example, memory controller 1043 may include a central processing unit (CPU), graphics processing unit (GPU), or other programmable general-purpose or special-purpose microprocessor, digital signal processor (DSP), programmable controller, application-specific integrated circuit (ASIC), programmable logic device (PLD), or other similar device or combination of these devices.

[0024] In some embodiments, the memory controller 1043 is also referred to as a flash memory controller or flash memory module. The memory module 1042 may receive a sequence of instructions from the memory controller 1043 and read data stored in the memory cells according to the sequence of instructions.

[0025] Figure 2 A schematic diagram of an exemplary memory controller 1043 according to an embodiment of this application is shown.

[0026] Please refer to Figure 1 and Figure 2 The memory controller 1043 includes a host system interface 12, a memory interface 16, and a memory control circuit 14. The host system interface 12 is used to connect to the host system 102 via a connection interface 1041 for communication with the host system 102. The memory interface 16 is used to connect to the memory module 1042 for access to the memory module 1042.

[0027] Memory control circuitry 14 is connected to host system interface 12 and memory interface 16. Memory control circuitry 14 can be used to control or manage the overall or partial operation of memory controller 1043. For example, memory control circuitry 14 can communicate with host system 102 via host system interface 12 and access memory module 1042 via memory interface 16. For example, memory control circuitry 14 may include control circuitry such as embedded controllers or microcontrollers. In the following embodiments, the description of memory control circuitry 14 is equivalent to the description of memory controller 1043.

[0028] In some embodiments, the memory controller 1043 may further include a buffer memory 20. The buffer memory 20 is connected to the memory control circuitry 14 and is used to cache data. For example, the buffer memory 20 may be used to cache instructions from the host system 102, data from the host system 102, and / or data from the memory module 1042. In particular, a logical-to-physical mapping table is typically resident or cached in the buffer memory 20 to support high-speed access and updates.

[0029] In some embodiments, the memory controller 1043 may further include an error checking and correction circuit 22. The error checking and correction circuit 22 is connected to the memory control circuit 14 and is used to encode and decode data to ensure data integrity. For example, the error checking and correction circuit 22 may support various encoding / decoding algorithms such as Low Density Parity Check code (LDPC code), BCH code, Reed-solomon code (RS code), and Exclusive OR (XOR) code. In some embodiments, the memory controller 1043 may also include other types of circuit modules (e.g., power management circuits), which are not limited in this application.

[0030] In some embodiments, the memory controller 1043 may further include a power management circuit 18. The power management circuit 18 is connected to the memory control circuit 14 and is used to control the power supply to the storage device 104.

[0031] Figure 3 A schematic diagram of an exemplary memory management module according to an embodiment of this application is shown.

[0032] Please refer to Figures 1 to 3 The memory module 1042 includes multiple physical units 301(0)-301(B). Each physical unit includes multiple storage cells for non-volatile data storage.

[0033] In some embodiments, an entity unit may include an entity programming unit. In some embodiments, an entity programming unit is also referred to as an entity programming unit. In some embodiments, an entity programming unit may be considered as an entity page.

[0034] In some embodiments, an entity programming unit may include multiple entity sectors. For example, the data capacity of an entity sector may be 512 bytes (B), and an entity programming unit may include 32 entity sectors. However, the data capacity of an entity sector and / or the total number of entity sectors included in an entity programming unit can be adjusted according to practical needs, and this application does not impose any limitations. For example, the storage capacity of an entity programming unit may be 16 kilobytes, and this application is not limited to this.

[0035] In some embodiments, a physical programming unit is the smallest unit of synchronously written data in the memory module 1042. For example, when performing a programming operation (also known as a write operation) on a physical programming unit to write data to that physical programming unit, multiple memory cells in that physical programming unit can be synchronously programmed to store the corresponding data. For example, when programming a physical programming unit, a write voltage can be applied to that physical programming unit to change the threshold voltage of at least some of the memory cells in that physical programming unit. For example, the threshold voltage of a memory cell may reflect the bit data stored in that memory cell.

[0036] In some embodiments, an entity erasure unit may comprise multiple entity programmatic units. In some embodiments, an entity erasure unit may be considered as an entity block.

[0037] In some embodiments, multiple programmed units in a physical erase unit can be erased simultaneously. For example, when an erase operation is performed on a physical erase unit, an erase voltage can be applied to multiple programmed units in this physical erase unit to change the threshold voltage of at least some of the memory cells in these programmed units. By performing an erase operation on a physical erase unit, the data stored in this physical erase unit can be erased.

[0038] In some embodiments, the memory control circuit 14 can logically associate physical units 301(0)-301(A) and 301(A+1)-301(B) with the data area 31 and the idle area 32, respectively. Physical units 301(0)-301(A) in the data area 31 all store data (also referred to as user data) from the host system 102. For example, any physical unit in the data area 31 can store valid data and / or invalid data. Furthermore, physical units 301(A+1)-301(B) in the idle area 32 do not store any data (e.g., valid data).

[0039] In some embodiments, if a unit does not store valid data, it may be associated with the free zone 32. Furthermore, units in the free zone 32 may be erased to clear the data within them. In some embodiments, units in the free zone 32 are also referred to as idle units. In some embodiments, the free zone 32 is also referred to as the free pool.

[0040] In some embodiments, when data needs to be stored, the memory control circuit 14 may select one or more physical units from the idle area 32 and instruct the memory module 1042 to store the data into the selected physical units. After the data is stored into this physical unit, this physical unit can be associated with the data area 31. In other words, one or more physical units can be used cyclically between the data area 31 and the idle area 32.

[0041] In some embodiments, the memory control circuit 14 may configure multiple logic units 302(0)-302(C) to map physical units (i.e., physical units 301(0)-301(A)) in the data area 31. For example, a logic unit may correspond to a logical block address (LBA) or other logical management unit. A logic unit may be mapped to one or more physical units.

[0042] In some embodiments, if a physical unit is currently mapped by any logical unit, the memory control circuit 14 can determine that the data currently stored in this physical unit includes valid data. Conversely, if a physical unit is not currently mapped by any logical unit, the memory control circuit 14 can determine that this physical unit does not currently store any valid data.

[0043] In some embodiments, the memory control circuit 14 may record the mapping relationship between logical units and physical units in at least one management table (also known as a logic-to-physical mapping table, or L2P table). In some embodiments, the memory control circuit 14 may instruct the memory module 1042 to perform operations such as data reading, writing, or erasing based on the information in this management table (i.e., the logical address to physical address mapping table).

[0044] Universal Flash Memory (UFS) technology has gradually become the mainstream memory technology in the market due to its high speed, low power consumption, and high reliability. To ensure the reliability and stability of UFS memory, effective testing is crucial.

[0045] In practical use, UFS storage requires the writing of boot information (i.e., system image and related configuration data) to devices such as mobile phones or development boards. This boot information typically occupies a portion of the storage area in the UFS storage. Furthermore, during system operation, the device may impose access protection or permission restrictions on certain partitions or critical data areas of the UFS storage. Therefore, when conducting functional and performance testing of UFS storage, the test environment cannot freely read, write, and manipulate the entire storage area of ​​the UFS storage, resulting in limited test coverage. This is especially true when dealing with system-reserved areas and operational scenarios strongly related to system operation, where testing capabilities are constrained.

[0046] During system operation, mechanisms such as energy-saving management and performance optimization are typically enabled, which may generate additional background access operations to the UFS storage. Since these operations are automatically scheduled by the system and difficult to control, it cannot be guaranteed that the UFS storage will only perform the intended test behaviors during testing. Therefore, current testing primarily focuses on system-level verification, placing the UFS storage in a complete operating environment for testing, making it difficult to achieve fully controllable independent test scenarios. When anomalies occur during testing, the system may continue to access the UFS storage, preventing the test from stopping immediately. Furthermore, system-level verification also makes it difficult to conduct targeted tests such as fault injection.

[0047] To comprehensively and accurately test UFS memory and address the issues of low test coverage, operational limitations, and difficulty in anomaly testing caused by system dependencies in existing testing solutions, this application provides a memory testing system and method to offer a fully programmable UFS testing approach without host system dependencies. This method can operate in both pure hardware-level and system-level testing modes, possessing core capabilities such as full command set support, full area access, full power programmability, anomaly simulation, real-time data verification, and multi-queue stress testing. It can achieve full coverage testing of UFS memory, both white-box and black-box.

[0048] Figure 4 A schematic diagram of the system architecture of an exemplary memory testing platform according to an embodiment of this application is shown.

[0049] like Figure 4As shown, in some embodiments, the system architecture includes a host computer control layer 402, a communication interface layer 404, a test platform core layer 406, and a power management module 408. The power management module 408 is a programmable power management module. The host computer control layer 402 can provide a graphical user interface (GUI) and script editing functions; the test platform core layer 406 can boot a customized system from an SD card and run a full-featured UFS memory test driver; and the power management module 408 can provide multi-channel independent programmable power control.

[0050] In some embodiments, the host computer control layer 402 may be GUI software running on a Windows / Linux system computer, used to provide a GUI test control interface, a test script editor, and real-time monitoring and log analysis functions. The host computer control layer 402 can send test commands, parameters, or scripts to the communication interface layer 404.

[0051] In some embodiments, the communication interface layer 404 can connect to the host computer and the test platform via a USB (Universal Serial Bus) or serial communication module, employing a hybrid mode of a custom communication protocol and an ADB (Android Debug Bridge) protocol adapter to achieve efficient command and data transmission. The communication interface layer 404 and the test platform core layer 406 can exchange commands and data.

[0052] In some embodiments, the core layer 406 of the test platform can be constructed using a general-purpose development board to form a test board for testing the memory. This test board achieves full command set support and full-area access by modifying or rewriting the driver layer of the UFS memory. A key innovation of this application embodiment is that it boots an independent test system image from a third-party storage medium (such as an SD card) independent of the memory, rather than booting an Android / Linux system (the operating system installed within the UFS memory) from within the UFS memory, thereby achieving complete control over the UFS memory. This image integrates a deeply customized Linux kernel to create a dedicated system node interface (such as creating the test node / sys / ufs_test) during system initialization to communicate with the host computer. The UFS test driver module supports a full set of functions for executing UFS test logic. The core layer 406 of the test platform can transmit power control signals to the power management module 408.

[0053] In some embodiments, the UFS test driver module is equipped with a full command support and data processing (protocol encapsulation) mechanism. The UFS test driver module can fully encapsulate the UFS protocol stack, supporting SCSI (Small Computer System Interface), Query, UIC Command (UniPro Interconnect Command), Task Management Command, and Vendor-Specific Command. Among these, SCSI commands are the primary command protocol used for data read and write operations in the UFS protocol. Query commands are mainly used to access the configuration parameters and attribute information of the UFS storage, and UIC commands are used to control the communication status of the UFS storage's link layer and physical layer. All commands can be custom-encapsulated through UPIU (UFS Protocol Information Unit), supporting abnormal data injection and protocol violation testing.

[0054] Figure 5 A schematic diagram of the internal mechanism of an exemplary UFS test driver module according to an embodiment of this application is shown.

[0055] To achieve comprehensive testing of UFS storage, this application embodiment constructs a modular command processing engine for UFS command issuance and data processing within the UFS test driver module. For example... Figure 5 As shown, the processing engine includes a command encapsulation layer 502, a UPIU assembly layer 504, a queue management module 506, a data transmission layer 508, and a UFS memory interface 510.

[0056] In some embodiments, the command encapsulation layer 502 provides encapsulators for all UFS protocol commands, including SCSI command encapsulators, Query command encapsulators, UIC command encapsulators, Vendor command encapsulators, etc. Users can directly edit command parameters (CDB) through the GUI interface of the host computer without needing to understand the underlying UPIU format.

[0057] In some embodiments, the UPIU assembly layer 504 can encapsulate higher-level commands into UPIU data units conforming to the UFS protocol. The UPIU assembly layer 504 supports command UPIU assembly, data UPIU assembly, and response UPIU parsing functions, and is key to implementing protocol conformance testing and error injection.

[0058] In some embodiments, the queue management module 506 is used to implement high-stress testing. This application embodiment can implement a 32-depth command queue. The UFS test driver module can continuously encapsulate multiple UPIUs and distribute them in batches through a "doorbell register" mechanism, maximizing bus utilization and command test density to simulate real high-load scenarios. The queue management module 506 also includes a task scheduler and a priority controller for managing the queue.

[0059] In some embodiments, the data transmission layer 508 includes data transmission and verification to ensure real-time data transmission. The data transmission layer 508 includes a real-time data verification module, an interrupt response processor, and an error injection engine. The real-time data verification module compares the read data immediately with a preset pattern (such as all 0s, all 1s, random numbers, or an increasing sequence) and reports the comparison result. The interrupt response processor handles interrupt signals generated after the UFS device completes command execution and parses the execution result and status to ensure that the UFS response can be processed immediately, reducing latency. The error injection engine actively constructs exception or error scenarios to test the fault tolerance and recovery capabilities of the UFS memory.

[0060] In some embodiments, the UFS memory interface 510 includes a UTP transport layer (UFS Transport Protocol) and an M-PHY (a high-speed physical interface specification) physical layer for transmitting encapsulated UPIU packets to the UFS memory.

[0061] This application's embodiment supports full-type command encapsulation, 32-depth command queue management, real-time data verification, and error injection capabilities within the internal components of the UFS test driver module. Compared to existing technologies, this internal mechanism significantly improves command queue depth, real-time verification accuracy, and error injection flexibility, and does not rely on the Android system's UFS driver stack. This internal mechanism ensures comprehensive, high-stress, and real-time testing, representing a qualitative improvement in testing depth, flexibility, and efficiency compared to existing technologies that only send limited commands through the Android interface.

[0062] In some embodiments, the power management module 408 can be a power subsystem independent of the main control board, which can independently and precisely program and control multiple programmable power supplies such as VCC, VCCQ, and VCCQ2 of the UFS memory. The microsecond-level power controller can support microsecond-level timing operations.

[0063] The power management module 408 is a multi-channel independent programmable power module that supports microsecond-level rapid power-on and power-off, as well as simulating abnormal power outage scenarios. In voltage disturbance testing, the VCC / VCCQ voltages can be randomly adjusted within a specified range to test the data protection capability of the UFS memory under unstable voltage conditions. In sleep mode testing, it supports both hold and disconnect sleep modes based on the VCC power supply voltage to verify the WB (Write Booster) write mechanism.

[0064] Figure 6 A schematic diagram of the architecture of a power management module 408 according to an embodiment of this application is shown.

[0065] To conduct reliability and robustness testing on UFS storage, such as Figure 6 As shown, in some embodiments, the programmable power management module 408 includes a monitoring feedback loop 602, a host computer control terminal 604, power control logic 606, a programmable power array 608, and a UFS memory power interface 610.

[0066] In some embodiments, the monitoring feedback loop 602 integrates a voltage sampling analog-to-digital converter (ADC), a current detection circuit, and a temperature sensor to feed back the power supply status to the host computer in real time, forming a closed-loop control to ensure the accuracy and repeatability of test conditions.

[0067] In some embodiments, the host computer control terminal 604 integrates a power control GUI, a voltage disturbance script, and a timing controller for receiving control commands and generating power control signals. The power control logic 606 integrates a microsecond-level timing generator, a voltage digital-to-analog converter (DAC) controller, and a multi-channel synchronization manager for generating microsecond-level precision timing control signals based on the power control signals. The programmable power array 608 integrates an adjustable VCC power channel (0.8~3.3V), an adjustable VCCQ power channel (1.2~1.8V), and an adjustable VCCQ2 power channel (1.7~3.3V) for outputting multiple independent programmable power supplies based on the timing control signals. The UFS memory power interface 610 integrates VCC, VCCQ, and VCCQ2 pins for connecting multiple independent programmable power supplies to their respective power pins on the memory. By independently setting the voltage value, power-on / off timing (microsecond precision), and ripple simulation for each power supply (VCC, VCCQ, and VCCQ2), fine-grained power control can be achieved.

[0068] In some embodiments, for abnormal power outage testing, while the UFS memory is performing a write operation, the power supply is suddenly cut off at a specified time using a microsecond-level timing generator to verify the UFS memory's sudden power loss data protection mechanism. In some embodiments, for voltage disturbance testing, a voltage disturbance script is written on a host computer to instruct the power management module 408 to dynamically reduce a certain voltage to outside the protocol's allowed range or a critical value within a specified time to test the UFS memory's operational stability and data integrity under unstable voltage conditions. In some embodiments, for sleep mode testing, VCC can be precisely controlled to remain or disconnect, combined with the driver sending sleep wake-up commands to test the UFS memory's sleep / active state switching and WB flush behavior.

[0069] This application's embodiments support microsecond-level precise control of multiple independent power supplies, and possess voltage disturbance injection and real-time monitoring capabilities. Compared to the simple power control in existing technologies, this application's embodiments provide more refined power management capabilities, supporting advanced testing scenarios such as abnormal power outages and voltage instability. This application's embodiments form the foundation for achieving hardware-level reliability testing, representing a core differentiating solution that pure software solutions or simple power control solutions cannot match.

[0070] In the test platform of this application embodiment, the UFS memory under test is used as the device under test. The test platform is connected to the interface of the UFS memory under test so that all storage areas of the memory (including the Boot Partition, user data area, system reserved area, and WLUN area) can be directly accessed by the test platform without the need to pre-install any operating system or file system in the UFS memory. By adopting a lightweight, high-privilege test path that independently boots from a third-party storage medium and has full control, direct control over the lowest level of the UFS memory is achieved.

[0071] like Figure 4 As shown, the test platform can selectively run in either pure hardware test mode or system-level test mode. In pure hardware test mode, the test platform first boots from a third-party storage medium independent of the memory to load a customized test system image and a customized kernel. This image integrates a reconstructed UFS test driver module. During the initialization phase, this test driver module disables the system's default power management, hibernation, and retry mechanisms to ensure that the UFS memory is in a fully controllable state. The test driver layer exposes complete test interfaces, communicating with the host computer through system nodes to receive test commands and return test status and test data.

[0072] Figure 7A flowchart illustrating an exemplary memory testing method 700 according to an embodiment of this application is shown. Figure 7 This illustrates the entire process of the test platform provided in this application embodiment, from startup to test execution.

[0073] As described above, the innovation of the memory testing method provided in this application lies in loading an independent test system from a third-party storage medium during the boot phase, rather than booting the Android system from UFS memory. The test driver layer interacts directly with the UFS memory, bypassing operating system limitations and supporting real-time control and data recording for abnormal test scenarios. Specifically, as Figure 7 As shown, the process of method 700 can be divided into four stages.

[0074] The first phase involves the startup and initialization of the test platform. In some embodiments, the test platform boots from a custom image on a third-party storage medium (e.g., an SD card) and loads a bootloader and a customized kernel to initialize the test platform. After the customized kernel boots, a reconstructed UFS test driver module is loaded. This UFS test driver module can disable the system's default power management mechanisms and / or retries; for example, it can disable the system's default power management and hibernation policies, and disable unnecessary background services and retry mechanisms. Next, a controlled power-on and basic initialization can be performed on the UFS memory, instead of a full system boot, to run operating system functions. A test node ` / sys / ufs_test` is created to create a dedicated test node in the ` / sys / ` file system, serving as a communication interface with the host computer for controlling or reading the UFS test status.

[0075] The second phase involves test readiness and connection completion. After driver initialization, in some embodiments, the UFS test driver module can send a "device ready" signal to the host computer via the test node (i.e., the communication interface). After the host computer identifies the device based on this signal, it can query device information, and the UFS test driver module can return UFS descriptor information, thus completing the connection between the host computer and the UFS memory under test.

[0076] The third stage is the test command execution stage. In some embodiments, users can select test items (e.g., single-step test or script test) and configure parameters through the host computer's GUI interface. The host computer will issue test commands and parameters, which are received and parsed by the test nodes. The UFS test driver module is also used to manage the management command queue to encapsulate UFS protocol commands (including at least one of SCSI, Query, UIC Command, Task ManagementCommand, and Vendor Specific Command) from multiple test instructions into UPIU packets, and send them to the UFS memory through the UTP transport layer and doorbell register mechanism.

[0077] After the UFS memory responds, it can return the response and captured data to the UFS test driver module in real time, and immediately stop the query of UFS memory data through the interrupt mechanism. The UFS test driver module then sends the test results to the test node based on the captured data, and the test node feeds back the test results and test status to the host computer for display in real time.

[0078] In some embodiments, during the test, the UFS test driver module can immediately trigger an interrupt mechanism after the UFS memory responds, enabling real-time data comparison and status feedback. This application embodiment can support high-speed data verification (e.g., cyclic redundancy check (CRC), simulated comparison, etc.), real-time log output (serial communication port or file), fault scene preservation, test pause, and status export.

[0079] Figure 8 A flowchart illustrating an exemplary memory testing method 800 according to an embodiment of this application is shown.

[0080] As an optional embodiment, such as Figure 8 As shown, the fourth stage is the advanced and anomaly testing stage. Users can send anomaly test commands to the UFS test driver module via a host computer. Taking the "abnormal power failure" test command as an example, the UFS test driver module is used to directly access all storage areas of the memory, including the boot partition, user data partition, reserved partition, and logical cell number partition. After receiving the anomaly test command from the host computer, the UFS test driver module can drive the power management module to execute an abnormal power failure or voltage disturbance command to cut off the power supply to the UFS memory within microseconds. After power is restored, the UFS test driver module can access specific areas of the UFS memory to verify data integrity or record the recovery status of the UFS memory, and return an anomaly test report to the host computer.

[0081] The method provided in this application is controllable throughout the entire process, free from system interference, and allows for real-time visibility of the UFS memory status. It also supports testing across all scenarios, from normal functionality to boundary anomalies.

[0082] To achieve graphical control and scripted testing, the host computer can provide a GUI testing interface. This GUI interface can include a command debugging interface, script editing and batch execution functions, a real-time monitoring interface, and data import / export functions. The command debugging interface supports single command execution, parameter configuration, and result viewing. The script editing and batch execution functions support scripted test processes, allowing for the continuous execution of multiple test items. The real-time monitoring interface displays test status, logs, power status, etc. The data import / export functions support uploading and downloading test data files.

[0083] Figure 9 A schematic diagram of the layout of an exemplary host computer GUI interface according to an embodiment of this application is shown.

[0084] To reduce testing complexity, the embodiments of this application provide, as follows: Figure 9 The GUI test interface shown is comprised of a high-frequency core function area 902, a low-frequency advanced function area 904, and an auxiliary function area 906.

[0085] In some embodiments, the high-frequency core functional area 902 includes a power control panel, a single-command debugger, and a real-time monitoring dashboard. The power control panel provides one-click operation for voltage setting, power-on / off, and disturbance testing. The single-command debugger allows editing and issuing arbitrary UFS commands in form or hexadecimal format, and real-time viewing of response UPIUs, making it a powerful tool for white-box debugging. The real-time monitoring dashboard centrally displays key indicators such as current test status, throughput, latency, power parameters, and chip temperature.

[0086] In some embodiments, the low-frequency advanced function area 904 includes a batch script editor, an anomaly test controller, and a data comparison tool. The batch script editor supports Python scripting syntax or scripting syntax such as Lua, allowing users to write complex multi-step test processes (e.g., sequential write-out-of-order read-abnormal power failure-recovery verification). The anomaly test controller provides templates and parameter configuration interfaces for test scenarios such as abnormal power failures, voltage disturbances, and command injection errors. The data comparison tool supports multiple comparison modes for read data and visualizes differences.

[0087] In some embodiments, the auxiliary function area 906 includes a log viewer and a test report generator. The log viewer is used to categorize and display system logs, command logs, and power logs, and supports filtering and retrieval. The test report generator is used to generate standardized test reports containing test configurations, process data, results, and charts with a single click.

[0088] The GUI testing interface provided in this application embodiment can encapsulate the complex underlying driver and power control capabilities into an intuitive and easy-to-use operating interface, greatly improving testing efficiency and user experience.

[0089] The above description of the embodiments is only for the purpose of helping to understand the method and core ideas of this application. It should be noted that, for those skilled in the art, several improvements and modifications can be made to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A memory testing system, comprising a testing platform and a host computer, characterized in that, The test platform is connected to the interface of the memory, and the test platform is used to selectively run in pure hardware test mode or system-level test mode. In the pure hardware testing mode, the test platform is used to boot from a third-party storage medium independent of the memory to load the test system image and a customized kernel to initialize the test platform. The image has integrated a reconstructed UFS test driver module, which interacts directly with the memory to bypass operating system restrictions. After the customized kernel starts, the test platform loads the test driver module and creates test nodes to create dedicated test nodes in the file system as a communication interface with the host computer. These nodes are used to control or read the test status of the memory. The test driver module is used to shield the system's default power management mechanism and / or retry mechanism, and communicates with the host computer through the test nodes to receive test instructions issued by the host computer for testing the memory and return the test status and test data of the memory to the host computer.

2. The memory testing system according to claim 1, characterized in that, The test driver module is also used to manage the command queue, so as to encapsulate the UFS protocol commands in multiple test instructions into UPIU packets and send them to the memory through the doorbell register mechanism; After the memory responds, the test driver module immediately triggers an interrupt mechanism to perform real-time data comparison and status feedback.

3. The memory testing system according to claim 2, characterized in that, The UFS protocol commands include at least one of the following: SCSI command, Query command, UIC Command command, Task Management Command command, and Vendor Specific Command command.

4. The memory testing system according to claim 1, characterized in that, The memory testing system also includes a test driver module and a power management module; The test driver module is used to directly access all storage areas of the memory, including the boot partition, user data partition, reserved partition, and logical unit number partition. The test driver module is also used to drive the power management module to execute an abnormal power-off or voltage disturbance command after receiving an abnormal test command sent by the host computer, so as to cut off the power supply to the memory within a microsecond. After the power management module is powered on again, the test driver module is also used to drive access to a specific area of ​​the memory to verify the integrity of the data in the memory or record the recovery status of the memory, and return an abnormal test report to the host computer.

5. The memory testing system according to claim 1, characterized in that, The host computer is used to provide a GUI test interface, which includes a command debugging interface, script editing and batch execution functions, a real-time monitoring interface, and data import and export functions. The command debugging interface is used to support single command execution, parameter configuration and result viewing functions, and the script editing and batch execution functions are used to support the scripting of the test process so as to execute multiple test items continuously; The data import / export function is used to support the uploading and downloading of test data files.

6. The memory testing system according to claim 5, characterized in that, The GUI test interface includes a high-frequency core function area, which includes a power control panel, a single-command debugger, and a real-time monitoring dashboard. The power control panel is used to provide voltage setting, power-on / off, and disturbance testing operations; The single-command debugger is used to edit arbitrary test commands in form or hexadecimal format and send them to the test driver module, and is used to view the response UPIU protocol commands in real time; The real-time monitoring dashboard is used to centrally display key indicators, including current test status, throughput, latency, power parameters, and chip temperature.

7. The memory testing system according to claim 5, characterized in that, The GUI test interface also includes a low-frequency advanced function area, which includes a batch script editor, an exception test controller, and a data comparison tool. The batch script editor is used to write test processes using script syntax, which includes Python script syntax or Lua script syntax. The anomaly test controller is used to provide templates and parameter configuration interfaces for test scenarios, and the test scenarios include at least abnormal power outages, voltage disturbances, and command injection errors. The data comparison tool is used to compare and visualize the differences between the read data using various comparison modes.

8. The memory testing system according to claim 5, characterized in that, The GUI test interface also includes an auxiliary function area, which includes a log viewer and a test report generator. The log viewer is used to categorize, display, filter, or retrieve system logs, command logs, and power logs. The test report generator is used to generate standardized test reports that include test configuration, process data, results, and charts.

9. The memory testing system according to claim 4, characterized in that, The power management module is a programmable power management module, used to programmatically control the multiple programmable power supplies of the memory.

10. The memory testing system according to claim 9, characterized in that, The power management module includes a monitoring feedback loop, a host computer control terminal, power control logic, a programmable power array, and a memory power interface. The monitoring feedback loop is used to feed back the power status to the host computer in real time. The host computer control terminal is used to receive control commands and generate power control signals; The power control logic is used to generate timing control signals with microsecond-level precision based on the power control signal; The programmable power array is used to output multiple independent programmable power supplies according to the timing control signal; The memory power interface is used to connect the multiple independent programmable power supplies to the corresponding power pins of the memory.

11. The memory testing system according to claim 10, characterized in that, The programmable power array includes a VCC power channel, a VCCQ power channel, and a VCCQ2 power channel; The voltage range configured for the VCC power channel is 0.8~3.3V, the voltage range configured for the VCCQ power channel is 1.2~1.8V, and the voltage range configured for the VCCQ2 power channel is 1.7~3.3V.

12. The memory testing system according to claim 4, characterized in that, The memory testing system is used for abnormal power failure testing. For the abnormal power failure test, when the memory is performing a write operation, the power supply is cut off at a specified time by controlling the microsecond-level timing generator to verify the memory's sudden power failure data protection mechanism.

13. The memory testing system according to claim 4, characterized in that, The memory testing system is also used for voltage disturbance testing. For the voltage disturbance test, the host computer sends an instruction to the power management module to dynamically reduce any voltage to a critical value within a specified time.

14. The memory testing system according to claim 4, characterized in that, The memory testing system is also used for sleep mode testing. For the sleep mode testing, the VCC power supply is kept on or off in conjunction with the hibernation wake-up command to test the switching between sleep / hold states of the memory and the refresh behavior of the buffer data.

15. A memory testing method, applied to the memory testing system as described in any one of claims 1-14, the method comprising: Receive test instructions for testing the memory; The test data of the memory is obtained according to the test instructions, and the test data and the test status of the memory are returned. The memory is connected to the memory test system.

Images