Memory Chip Testing Methods and Systems

Abstract

The embodiment of the application discloses a kind of storage chip test method and system.The method comprises: request server side to issue communication keeping command according to preset time interval;The command issued by server side is parsed, and communication keeping command or test command pre-subscribed by MQTT protocol is obtained, and the command issued by server side is set to preset fixed data format;In response to the communication keeping command, continue to wait for the test command;In response to the test command, retrieve and execute corresponding test case in local storage structure, and report test result to server side by MQTT protocol in one or more times according to pre-published result theme, wherein the test result is set to have fixed data format matched with the test command.The application can effectively reduce test equipment and test environment complexity, reduce resource and cost consumption, prevent packet loss unpacking, and guarantee test reliability and integrity.

Description

Technical Field

[0001] This application relates to the field of chip testing, and more particularly to a method and system for testing memory chips. Background Technology

[0002] Traditional memory chip testing systems often employ a closed architecture, typically relying on dedicated hardware interfaces (such as JTAG, I²C, or parallel buses) for localized testing. They generally lack built-in wireless communication capabilities and supporting network protocol stacks. When such systems need to be integrated into remote monitoring or distributed testing platforms, they often face high hardware modification costs or complex software refactoring, making it difficult to achieve low-cost, rapid deployment, and intelligent upgrades.

[0003] Although some solutions attempt to achieve network connectivity through external USB to Ethernet / WiFi modules, their communication protocols are mostly general standards (such as TCP / HTTP) and are not optimized for the low bandwidth, high latency, and packet loss characteristics of embedded testing scenarios. This results in frequent command packet unpacking, response timeouts, or data loss in weak network environments, which seriously affects the reliability and integrity of the test. Summary of the Invention

[0004] This application provides a memory chip testing method, testing equipment, and computer program product to effectively reduce the complexity of testing equipment and testing environment, reduce resource and cost consumption, prevent packet loss and packet splitting, and ensure testing reliability and integrity.

[0005] In a first aspect, embodiments of this application provide a method for testing a memory chip. The remote testing method is applied to at least one embedded testing terminal configured with the MQTT protocol. The method includes: Request the server to send a communication hold command at preset time intervals; The commands sent by the server are parsed to obtain the communication hold command or the test command pre-subscribed through the MQTT protocol. The commands sent by the server are set to a preset fixed data format. In response to the communication hold command, continue to wait for the test command; In response to the test command, the corresponding test case is retrieved from the local storage structure, and the test results of executing the test case are reported to the server in one or more installments via the MQTT protocol according to the pre-published result topic. The test results are set to have a fixed data format that matches the test command.

[0006] By implementing the embodiments of this application, the memory chip testing method is applied to an embedded test terminal configured with the MQTT protocol (i.e., the embedded test terminal is directly used as the test execution subject), which effectively reduces the complexity of test equipment and test environment, makes upgrades easy, and reduces resource and cost consumption.

[0007] Secondly, embodiments of this application also provide a method for testing a memory chip, wherein the method is applied to a server configured with the MQTT protocol, and the method includes: In response to a request from the embedded test terminal, a communication hold command is sent to the embedded test terminal at preset time intervals; In response to a pre-subscribed command topic on the embedded test terminal, a test command is sent to the embedded test terminal, and the test command is set to a preset fixed data format; In response to a pre-published result topic from the embedded test terminal, the test results reported by the embedded test terminal are received, wherein the test results are set to have a fixed data format that matches the test command.

[0008] Thirdly, embodiments of this application provide a memory chip testing system, the testing system including a server and at least one embedded testing terminal, the method including: It is understood that the memory chip testing method in the second aspect and the memory chip testing system provided in the third aspect correspond to or are used to execute the method provided in the first aspect. Therefore, the beneficial effects they can achieve can be referred to in the beneficial effects of the method provided in the first aspect, and will not be repeated here.

[0009] The beneficial effects of this application are: This application innovatively proposes a lightweight distributed testing method for storage chips based on the MQTT protocol, achieving low-cost remote upgrades without hardware modifications. On one hand, it employs a customized three-layer nested data format to support multi-tasking, loop control, and type customization, effectively decoupling command parsing and test case execution. On the other hand, in an operating system-less environment, it utilizes a first designated memory region to construct a unidirectional test case linked list, enabling dynamic registration and efficient, secure invocation of test cases. Simultaneously, combined with packet reporting and weak network adaptation mechanisms, it significantly improves communication reliability. The overall solution substantially reduces system complexity, resource consumption, and deployment costs, solving core pain points of traditional testing systems such as difficulty in networking, unromantic protocols, and tightly coupled architectures. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of the architecture of the test system according to an embodiment of this application.

[0012] Figure 2 This is a schematic flowchart of a memory chip testing method according to an embodiment of this application.

[0013] Figure 3 This is a schematic diagram of the test case registration process in an embodiment of this application.

[0014] Figure 4 This is a schematic diagram of the test case storage process in an embodiment of this application.

[0015] Figure 5 This is a schematic diagram of the test case retrieval and execution process in the embodiments of this application.

[0016] Figure 6 This is a schematic flowchart of a memory chip testing method according to an embodiment of this application.

[0017] Figure 7 This is a schematic flowchart of a memory chip testing method according to an embodiment of this application.

[0018] Figure 8 This is a schematic diagram of the architecture of the embedded test terminal according to an embodiment of this application.

[0019] Figure 9 This is a schematic diagram of the structure of the test equipment according to an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be described in detail below with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other. 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.

[0021] It should be noted that: throughout the accompanying drawings, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions; in the description of this application, the terms "center," "longitudinal," "lateral," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on the scope of protection of this application; in the description of this application, "first," "second," etc., are only used to distinguish each other, and do not indicate their degree of importance or order, etc.

[0022] In the description of this application, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linkage" should be interpreted broadly. For example, they can refer to fixed connections, movable connections, or detachable connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; they can refer to the internal communication between two components, etc. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0023] With the rapid development of electronic technology, chip testing plays a crucial role in the production and R&D of electronic products. Traditional chip testing systems typically use a method where test boards are directly connected to a computer via a serial port. The computer receives test commands via a network or script and then sends these commands to the test boards for testing. This testing method requires a computer for each test board, or multiple test boards connected via a serial port splitter. The testing environment is complex and resource-intensive, especially when large-scale parallel testing is required, resulting in messy device connections and difficult management.

[0024] MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol designed for the Internet of Things (IoT) and low-bandwidth, unstable network environments. It enables message sending and receiving through a publish / subscribe topic approach.

[0025] Please refer to Figure 1 The memory chip testing system of this application embodiment mainly includes: Server-side; One computer can be set up as a server to serve as a remote control center. An MQTT server can be downloaded and deployed on this computer for sending test commands and receiving and displaying test results.

[0026] Embedded test terminal; Several test machines (test boards) based on embedded platforms can be set up as embedded test terminals to complete the physical connection of the SD card terminal test system. It includes an SD card slot, a USB interface and a serial port. The SD card slot is used to insert SD cards, the USB interface is used to connect a USB to network card module, and the network card module is connected to the network through a network cable to establish a communication connection with the server.

[0027] Debugging terminal; One computer can be set up as a debugging terminal and connected to at least one embedded test terminal via a serial port. After the embedded test terminal enters the debugging mode, debugging commands are sent to it to assist in troubleshooting test anomalies.

[0028] Please refer to Figure 2 This application provides a method for testing a memory chip, which is applied to at least one embedded test terminal configured with the MQTT protocol. The method includes: In step S110, a communication hold command is requested from the server at preset time intervals; In step S121, the command sent by the server is parsed to obtain the communication hold command or the test command pre-subscribed through the MQTT protocol. The command sent by the server is set to a preset fixed data format. In step S131, in response to the communication hold command, continue to wait for the test command; In step S132, in response to the test command, the corresponding test case is retrieved and executed in the local storage structure, and the test results obtained from executing the test case are reported to the server in one or more installments via the MQTT protocol according to the pre-published result topic. The test results are set to have a fixed data format that matches the test command.

[0029] By implementing the embodiments of this application, the memory chip testing method is applied to an embedded test terminal configured with the MQTT protocol (i.e., the embedded test terminal is directly used as the test execution subject), which effectively reduces the complexity of test equipment and test environment, makes upgrades easy, and reduces resource and cost consumption.

[0030] Please refer to Figure 3 In at least one possible implementation, the method further includes: In step S201, in response to the test case registration request, a preset test case registration macro is started, and the test case information to be registered is written into the first specified memory area according to the predefined test case description structure format. The test case description structure includes a test case name field, a maximum number of parameters field, and a function pointer field pointing to the corresponding test case execution function. In step S202, a new use case node is created in a preset use case chain list, wherein the new use case node includes at least: The first structure pointer is used to point to the current use case description structure; The second structure pointer is used to point to the next use case description structure.

[0031] By implementing the embodiments of this application, the test case registration macro writes test cases into a first designated memory area in a predefined test case description structure format, and constructs a test case linked list using the first designated memory area in an operating system-free environment, thereby realizing dynamic registration and efficient and secure invocation of test cases without recompiling or burning the entire terminal program. This can greatly improve the flexibility of test system maintenance and updates, and ensure the determinism of test case information storage and access efficiency.

[0032] Please refer to Figure 4 In at least one possible implementation, writing the test case information to be registered into a fixed inner area according to a predefined test case description structure format specifically includes: In step S2011, the use case list is traversed to locate the end node of the current linked list; The address of the next available first specified memory region is determined based on the second structure pointer contained in the end node; In step S2012, one or more test case description structures containing test case information to be registered are written into the first designated memory area.

[0033] By implementing the embodiments of this application, the target storage area address can be found through the second structure pointer, which enables simple, efficient and accurate storage of test cases.

[0034] In at least one possible implementation, the current use case description structure is sequentially written to the end of the first specified memory region, and the corresponding new use case node is appended to the end of the use case linked list, thereby maintaining the use case list as a complete singly linked list structure.

[0035] By implementing the embodiments of this application and constructing a unidirectional use case linked list, adding a new use case only requires adding a node to the end of the linked list, without affecting the existing structure.

[0036] Please refer to Figure 5 In at least one possible implementation, retrieving and executing the corresponding test cases from the local storage structure specifically includes: In at least one possible implementation, retrieving and executing the corresponding test cases in the local storage structure specifically includes: In step S203, each use case node in the use case linked list is traversed, and the use case description structure pointed to by the first structure pointer in each use case node is obtained in turn. In step S204, the use case name field in the use case description structure is matched with the input query conditions; If a match is found, check whether the number of input parameters does not exceed the value limited by the maximum number of parameters field in the use case description structure. If the validation passes, the corresponding test function is called through the function pointer field in the test case description structure to execute the test case.

[0037] By implementing the embodiments of this application and traversing to find the test case nodes in the test case chain, test cases can be invoked simply, efficiently, and accurately.

[0038] In at least one specific embodiment, the method further includes: In step S205, the test result information of the test case is written into the second designated memory area according to the predefined result information structure format, wherein the result information structure includes a key name and a key value; Create a new result node in a pre-defined result list, wherein the new result node includes at least: The third structure pointer is used to point to the currently written result information structure; The fourth structure pointer is used to point to the next result information structure.

[0039] In at least one specific implementation, after creating a new node in the preset result chain, the method further includes: after reporting the test result information, clearing the corresponding node in the result chain; In at least one specific implementation, the result information structure is sequentially written to the end of the second specified memory region, and the corresponding new node is appended to the end of the result information linked list, thereby maintaining the result information linked list as a complete singly linked list structure.

[0040] In at least one possible implementation, the commands issued by the server are set to a fixed data format, specifically including: The fixed data format is configured with a layered structure including a message layer, a task layer, and a control layer, wherein: The message layer includes at least a command identifier field, a command protocol version field, and a task array field; The task layer is embedded in the task array field and contains at least one task object. Each task object includes at least a task identifier field, a task type code field, a task type version field, a general input parameter field, and a specific input parameter field. The control layer is embedded in the general input parameters and includes a logical parameter field for controlling the task execution loop. The logical parameter includes at least one of the loop count, total execution time, and loop interval.

[0041] Implementing the embodiments of this application, a customized three-level nested data format is used to support multi-tasking, loop control and type customization, effectively decoupling command parsing and test case execution.

[0042] In at least one possible implementation, the test results are set to have a fixed data format that matches the commands issued by the server, specifically including: The fixed data format of the test results report fully includes the fixed data format of the commands issued by the server, and adds a general output parameter field and a specific output parameter field to each task object; By implementing the embodiments of this application, the result reporting format is complete and includes the command issuance format, a strict input-output correspondence is established, and the full-link traceability of test results is realized, effectively preventing issues such as packet splitting or packet loss.

[0043] The general output parameter fields include at least a result unique identifier field for identifying the test result reported this time, a task execution status field, and a client identifier field for identifying the source of the result; In at least one possible implementation, the general output parameters also include the total number of packets and the current packet sequence number, to support the packetized transmission of task execution results; The specific output function field is customized according to the task category defined by the task type code, and is used to transmit the configuration information required for the corresponding task category.

[0044] By implementing the embodiments of this application and setting the total number of packets and the current packet sequence number in the general output parameters, the problem of reliable transmission of large-volume test results (such as long logs and memory images) on unreliable networks can be directly solved.

[0045] In at least one possible implementation, the content of the specific input parameter is customized according to the task category defined by the task type encoding, and is used to convey the specific configuration information required for that category of task.

[0046] By implementing the embodiments of this application and setting customizable specific parameters, it provides strong scalability and expressiveness for various custom test tasks.

[0047] In at least one possible implementation: If the current task object's loop count and total execution time are both empty or configured to zero, the corresponding task will be executed once. When the number of times the current task object is executed in a loop or the total execution time is configured to be a non-zero value, the corresponding task is executed repeatedly until the configuration condition is met; When both the number of times the loop is executed and the total execution time are configured to be non-zero, the corresponding task is executed repeatedly until any configuration condition is met. The loop interval takes effect when the task is configured to execute in a loop.

[0048] By implementing the embodiments of this application, the logical parameters of the control layer (number of loop executions, total execution time, loop interval) provide flexible and powerful task orchestration capabilities.

[0049] Please refer to Figure 2 In at least one possible implementation, after parsing the command issued by the server, the method further includes: In step S133, in response to the exit test mode command issued by the server, the system exits test mode and enters debug mode; and / or In step S133, if the communication hold command is not received within a preset time, the test mode is exited and the debug mode is entered.

[0050] Implementing the embodiments of this application provides a clear state exit mechanism to prevent the embedded test terminal from being permanently stuck in the test waiting state under abnormal circumstances (such as server crash or permanent network interruption), thereby achieving fault isolation and self-recovery.

[0051] In at least one possible implementation, entering debug mode specifically includes: In step S1331, a debugging command is received from the debugging terminal through the local debugging interface, and the debugging command is executed on the local end; By implementing the embodiments of this application, a local debugging interface is supported in debug mode, allowing for terminal diagnosis and repair without relying on cloud servers, significantly reducing the difficulty and cost of on-site maintenance.

[0052] In at least one possible implementation, after entering debug mode, the method further includes: Re-enter the test mode until the test result is successful.

[0053] By implementing the embodiments of this application, a closed loop for problem repair is ensured by setting the loop condition to "test result successful" in the loop control logic.

[0054] Please refer to Figure 6 This application also provides a method for testing a memory chip, which is applied to a server configured with the MQTT protocol. The method includes: In step S210, in response to the communication request from the embedded test terminal, a communication hold command is sent to the embedded test terminal at preset time intervals; In step S220, in response to the command topic pre-subscribed by the embedded test terminal via the MQTT protocol, a test command is sent to the embedded test terminal, and the command is set to a preset fixed data format; In step S230, in response to the result topic pre-published by the embedded test terminal via the MQTT protocol, the test result reported by the embedded test terminal is received, wherein the test result is set to have a fixed data format matching the command.

[0055] The various commands and test results in this application embodiment have the same fixed data format and corresponding technical effects as any implementation in the foregoing embodiments, and will not be repeated here.

[0056] In at least one possible implementation, the method further includes: In step S240, the test results reported by the embedded test terminal are analyzed. If the result is a test failure, an exit test mode command is sent to the embedded test terminal.

[0057] Please refer to Figure 7 This application provides a method for testing memory chips. The remote testing method is applied to a testing system configured with the MQTT protocol. The memory chip testing system includes a server and at least one embedded testing terminal. The method includes: In step S110, the embedded test terminal requests the server to send a communication hold command at preset time intervals; In step S210, the server responds to the communication request from the embedded test terminal by sending a communication hold command to the embedded test terminal at preset time intervals. In step S220, the server responds to the command topic pre-subscribed by the embedded test terminal via the MQTT protocol and sends a test command to the embedded test terminal. The command sent by the server is set to a preset fixed data format. In step S121, the embedded test terminal parses the command sent by the server to obtain the communication hold command or test command; In step S131, the embedded test terminal responds to the communication hold command and continues to wait for the test command; In step S132, the embedded test terminal responds to the test command, retrieves and executes the corresponding test case in the local storage structure, and reports the test results of the executed test cases to the server in one or more installments via the MQTT protocol according to the pre-published result topic. The test results are set to have a fixed data format that matches the command issued by the server. In step S230, the server responds to the result topic pre-published by the embedded test terminal and receives the test results reported by the embedded test terminal via the MQTT protocol.

[0058] In at least one possible implementation, the method further includes: In S240, the server parses the test results reported by the embedded test terminal. If the result is a test failure, the server sends an exit test mode command to the embedded test terminal. and / or If the embedded service terminal responds to the exit test command, or does not receive the communication hold instruction after a preset time, it exits the test mode and enters the debug mode. and / or The test results reported by the embedded test terminal fully contain the fixed data format of the test commands.

[0059] In at least one possible implementation, entering debug mode specifically includes: Receive debugging commands from the debugging terminal via the local debugging interface, and execute the debugging commands locally; and / or After entering debug mode, the process also includes: re-entering test mode until the test result is successful.

[0060] Please refer to Figure 8 For example, the layered structure of the embedded test terminal in this application embodiment is as follows: Network communication layer: It includes a USB to network adapter module, which integrates the MQTT protocol and is responsible for converting between the MQTT and USB protocols, enabling network communication via USB, and is also the foundation for completing command topic publishing and subscription.

[0061] Transaction processing layer: It includes a protocol processing module, a network communication monitoring module, a debugging module, and a test case module.

[0062] The protocol processing module is responsible for parsing the received commands and providing test result storage and reporting.

[0063] The received commands mainly include communication hold commands, test commands, and exit test mode commands. The communication hold command is used to maintain the network connection between the embedded test terminal and the server to confirm that the communication link is working properly. The test command is used to issue specific test tasks to the embedded test terminal and specify the test rules and parameters. The exit test command is used to instruct the embedded test terminal to stop the current test task and switch to debug mode.

[0064] The network communication monitoring module is implemented through a timer. It issues a network monitoring command at preset time intervals (e.g., every 20 minutes). This command will trigger the issuance of a communication hold command. By monitoring whether the communication hold command has been issued, it can be confirmed whether the network communication is normal.

[0065] The debugging module includes commonly used debugging interfaces, provides common debugging commands, and connects to the serial port and the computer. It is used to facilitate developers in analyzing problems when test cases are abnormal. After entering the debugging mode, it sends debugging commands through the serial port to realize problem analysis.

[0066] The test case module is used to register, retrieve and execute test cases, save execution results (i.e., test results), and upload test cases.

[0067] Driver layer: It includes a USB driver module, an SD card driver module, a serial port driver module, and a timer driver module. It provides the transaction processing layer with the ability to transfer data between itself and hardware devices; only with the help of drivers can the two communicate and perform specific functions.

[0068] Interface layer: This device is used for installing and testing SD cards and connecting to a computer for debugging. It includes an SD card slot and a serial port, providing physical connections. The SD card slot is used to install the storage chip under test, and the serial port is used to connect to a debugging terminal for local debugging.

[0069] The two working modes are defined as follows: Debugging mode: In the debugging mode, the network connection port is disabled, and the system connects to the server through the debugging interface to receive and execute debugging commands issued by the server through the local interface.

[0070] Test mode: In the test mode, the system connects to the server via a network connection port, receives and executes test commands issued by the server through the network connection port.

[0071] Embedded test terminals can be implemented on embedded platforms (such as XU4). A hierarchical management system for building memory chip terminal test systems is constructed to deploy test equipment and support memory chip testing. This process includes at least the following tasks: Complete user registration and command topic configuration, and connect the test machine to the network test environment; Using a USB-to-network adapter module to achieve network communication simplifies cabling and reduces system upgrade costs; The transaction processing layer parses test commands, uses the test case management module to retrieve and test test cases, and finally reports the results according to the protocol. It also has network communication monitoring functions to prevent network interruptions. In addition, it implements a debugging module to facilitate timely debugging of test cases after an anomaly. Define a standardized protocol format to decouple test case registration, command reception, and result feedback, so that test case writers do not need to pay attention to protocol details, while solving the problems of packet splitting and packet loss in network transmission; The test case module and protocol processing module use a linked list with a specific format to implement test result storage, test case registration, and retrieval functions.

[0072] The process of implementing the above tasks in the embodiments of this application is described below by way of example.

[0073] Terminal registration: The embedded test terminal submits a registration request to the server, setting registration information such as terminal identifier and terminal permissions. After registration, the server stores the embedded test terminal's registration information in the database for subsequent connection verification.

[0074] The embedded test terminal communicates with the server via the MQTT protocol. The test terminal receives commands from the server and returns test results to the server by subscribing to topics and publishing topics.

[0075] Each embedded test terminal can be configured with two subscription topics and one publication topic.

[0076] One subscription topic is used to receive general commands issued by the server for all embedded test terminals, and another subscription topic is used to issue specific commands for this embedded test terminal; a publishing topic sends the test results of all test boards.

[0077] After setting the command subscription topic and result publishing topic on the server according to the MQTT protocol, enter test mode; The test commands sent from the server to the test terminal use a fixed data format, which includes the unique identifier of the current command, the command protocol version, and the task list. Each task includes a unique task identifier, task code, task category version, general input parameters (general input parameters include the number of loops, execution duration, and loop interval) and specific input parameters of JSON type (custom extensions are supported). Among them, the loop count and test duration in the general input parameters follow special configuration rules. When the loop count or test duration is configured to 0 or not configured, the default value of the loop count will be used. When both the loop count and test duration are configured, the task will be terminated when either condition is met. When both the loop count and test duration are configured to 0 or not configured, the task will be executed with the system default loop count.

[0078] When the test terminal reports results, in addition to retaining the core fields of the issued command, it adds general output results and specific output results: the general output results include a unique identifier for the result (i.e., it must be unique when sent back multiple times), packet transmission information (the packet transmission information includes the total number of packets and the current packet sequence number), task execution status, and device unique identifier; for example, the specific output structure is of JSON type, which is used to store personalized result data.

[0079] Use case registration: The embedded test terminal's test case module provides a test case registration interface, allowing test case writers to register test cases through this interface. In response to test case registration requests submitted by developers through the user interface, the test case module allocates a contiguous dedicated storage area in the fixed memory space of the local storage structure, encapsulates the request information (including test case name, maximum number of parameters, execution function, usage instructions, etc.) into a test case description structure, and stores it in this area to complete the test case registration.

[0080] Use case retrieval and execution: The protocol processing module passes the decoupled test case name to the test case module. The test case module looks up the corresponding test case description structure in the dedicated storage area according to the name, and triggers the execution of the test case through the function pointer in the test case description structure.

[0081] Test process: After the embedded test terminal is started, its transaction processing layer network communication monitoring module sends a communication hold command request to the specified topic on the server through the MQTT protocol of the network communication layer at a preset time interval (such as 20 seconds), triggering the server to issue a communication hold command to confirm the network communication status.

[0082] After receiving a communication hold request from the embedded test terminal, the server starts a timer and sends a communication hold command to the test terminal's dedicated subscription topic at time intervals consistent with the test terminal's preset intervals. For example, the command can be in a fixed JSON format, and the task code can be set to "0x00000001" for terminal identification.

[0083] Simultaneously, the server generates test commands based on the test task plan. These commands are encapsulated in a preset JSON format, including fields such as command ID, protocol version, task list, task code, and general parameters. Subsequently, the server distributes the test commands to the target terminal through a pre-subscribed dedicated topic or broadcast topic on the embedded test terminal.

[0084] After the embedded test terminal receives the command issued by the server, the protocol processing module of the transaction processing layer parses the command according to a unified data format (such as JSON protocol format), and distinguishes the command type by recognizing the task encoding field in the command to determine the current command type.

[0085] For example, when the task code is "0x00000001", it is determined to be a communication hold command, and the test terminal will maintain the network connection and continue to wait for the test task; when the task code is "0x00000006", it is determined to be a test command, and parameters such as test case name, number of loops, and test duration are extracted from the test command.

[0086] Once the protocol processing module confirms that the command type is a communication hold command, the embedded test terminal maintains the current test mode. The network communication monitoring module continues to send communication hold requests at preset time intervals. At the same time, the protocol processing module continuously listens to the subscribed topic and waits for the server to issue test commands. During this period, it is not necessary to interrupt the normal operation of other modules.

[0087] After the protocol processing module decouples the server-side command, if it determines that the command is a test command, it switches to test mode, enables the command reception and result reporting function of the network communication port, controls the SD card under test through the SD card driver module, executes the test operation according to the parameters in the test command, and records the test data in real time; at the same time, it can close the local debugging response that is not related to the test (only retain the network-related functions) to ensure that the test process is not disturbed.

[0088] The embedded test terminal protocol processing module packages and reports test data in a fixed data format (such as JSON) that matches the commands issued by the server. It iterates through each result node in the result information linked list, assembling the information of each result node into specific output parameters using key-value pairs, and then assembling the common output parameters based on the total number of bytes in the result information to determine the number of packets. If the data volume is small, it is reported all at once; if the data volume is large, it is reported multiple times through a publishing topic according to the packetization rules. The reported test results fully contain the fixed format fields of the test commands. The reported information includes the SD card information required to issue the commands and the test case execution results (i.e., test results).

[0089] The server subscribes to the result publishing topics of all embedded test terminals and listens for test results reported by these terminals in real time. Upon receiving a result, it first verifies the format integrity, confirming that the result contains core fields such as the command identifier, protocol version, and task code corresponding to the test command, ensuring that the result matches the command. For results reported in sub-packages, the server reassembles the data according to the sub-package sequence number to form a complete test result and stores it in the database.

[0090] The server decouples and parses the received complete test results to extract the task execution status and specific test data. If the test result is determined to be a failure, a command to exit test mode is generated and sent according to the terminal's exclusive subscription topic.

[0091] If the embedded test terminal receives the command to exit test mode or does not receive a communication hold instruction within a preset time, it will exit test mode and enter debug mode.

[0092] After the embedded test terminal enters debug mode, it disables the network connection port and connects to the debug terminal through the local debug interface (serial port), waiting for debug commands. After receiving the debug command, the debug module of the terminal transaction processing layer calls the corresponding execution function to perform the debug operation on the local end and return the result.

[0093] After troubleshooting and resolving the issue through the debugging terminal, you can receive a command to re-enter test mode, save the debugging record, exit debug mode, re-enable the network connection port, send a communication hold request to the server according to the initial procedure, wait for the server to reissue the test command, and repeat the test process until a successful test result is obtained.

[0094] If the server issues a command to exit test mode due to test failure, the terminal protocol processing module will immediately stop the current test task, save the test data, exit test mode and enter debug mode after parsing.

[0095] After the network communication monitoring module sends a communication hold request, if it does not receive a communication hold command from the server within a preset time, it is determined that the network communication is abnormal. The terminal automatically saves the current test state, exits the test mode, and enters the debug mode.

[0096] In debug mode, you can receive and execute debug commands from the debug terminal through the local debug interface. After debugging is complete, you can re-enter test mode until the test result is successful.

[0097] This application innovatively proposes a lightweight storage chip testing method based on the MQTT protocol, enabling low-cost remote upgrades without hardware modifications. On one hand, it employs a customized three-layer nested data format to support multi-tasking, loop control, and type customization, effectively decoupling command parsing and test case execution. On the other hand, in an operating system-less environment, it utilizes a fixed memory area to construct a unidirectional test case linked list, achieving dynamic registration and efficient, secure invocation of test cases. Simultaneously, combined with packet reporting and weak network adaptation mechanisms, it significantly improves communication reliability. The overall solution substantially reduces system complexity, resource consumption, and deployment costs, solving core pain points of traditional testing systems such as difficulty in networking, unromantic protocols, and tightly coupled architectures.

[0098] Please refer to Figure 9 This application also provides a memory chip testing system, including a processor 100 and a memory 200. The memory 200 is coupled to the processor 100 and is used to store computer program code, which includes computer instructions. When the processor 100 reads the computer instructions from the memory 200, the processor 100 executes the steps in the memory chip distributed testing method of any possible implementation of any of the foregoing embodiments.

[0099] This application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to perform the steps in the distributed testing method for memory chips in any of the possible implementations of the foregoing embodiments.

[0100] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0101] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the appended claims.

Claims

1. A memory chip testing method, characterized by, The storage chip test method is applied to at least one embedded test terminal configured with an MQTT protocol, and the method comprises the following steps: Requesting a server to issue a communication maintenance command at a preset time interval; Analyzing the command issued by the server to obtain the communication maintenance command or a test command pre-subscribed through the MQTT protocol, wherein the command issued by the server is set to a preset fixed data format; In response to the communication maintenance command, continuing to wait for the test command; In response to the test command, retrieving and executing a corresponding test case in a local storage structure, and reporting test results obtained by executing the test case to the server through the MQTT protocol in one or more times according to a pre-published result topic, wherein the test results are set to have a fixed data format matched with the command issued by the server.

2. The memory chip testing method of claim 1, wherein, The method further comprises the following steps: In response to a test case registration request, starting a preset case registration macro, and writing test case information to be registered into a first specified memory area according to a pre-defined case description structure format, wherein the case description structure comprises at least a case name field, a maximum parameter number field, and a function pointer field pointing to a corresponding test case execution function; Creating a new case node in a preset case link list, wherein the new case node comprises at least a first structure pointer pointing to the currently written case description structure, and a second structure pointer pointing to a next case description structure.

3. The memory chip testing method of claim 2, wherein, The step of writing the test case information to be registered into the first specified memory area according to the pre-defined case description structure format specifically comprises the following steps: Traversing the case link list to locate a last case node of the link list; Determining a next available first specified memory area address according to the second structure pointer contained in the last case node; Writing one or more case description structures carrying the test case information to be registered into the first specified memory area.

4. The storage chip test method according to claim 3, wherein The case description structures are sequentially written into a last position of the first specified memory area, and a corresponding new case node is added to a last position of the case link list, so that the case link list is maintained as a complete single-direction link list structure.

5. The memory chip testing method of claim 2, wherein, The step of retrieving and executing the corresponding test case in the local storage structure specifically comprises the following steps: Traversing each case node in the case link list to sequentially obtain a case description structure pointed to by the first structure pointer in each case node; Matching a case name field in the case description structure with an input query condition; If the matching is successful, checking whether the number of input parameters exceeds a value defined by a maximum parameter number field in the case description structure; If the checking is passed, calling a corresponding test function through the function pointer field in the case description structure to execute the test case.

6. The memory chip testing method according to any one of claims 1 to 5, wherein, The method further comprises the following steps: Writing test results obtained by executing the test case into a second specified memory area according to a pre-defined result information structure format, wherein the result information structure comprises a key name and a key value. A new result node is created in the preset result linked list, and the new result node at least includes: a third structure pointer for pointing to a currently written result information structure; and a fourth structure pointer for pointing to a next result information structure.

7. The memory chip testing method of claim 6, wherein, After the use case execution ends, the method further includes: After the new result node is created in the preset result linked list, the method further includes: after the test result information is reported, the corresponding result node in the result linked list is cleared; and / or The result information structure is sequentially written to a tail position of the second specified memory area, and the corresponding new result node is appended to a tail position of the result information linked list, so that the result information linked list is maintained as a complete unidirectional linked list structure.

8. The memory chip testing method according to any one of claims 1 to 5, wherein, The command issued by the server end is set to a fixed data format, and specifically includes: The fixed data format is set to a three-layer nested structure including a message layer, a task layer and a control layer, wherein: The message layer at least includes a command identification field, a command protocol version field and a task array field; The task layer is embedded in the task array field and contains at least one task object, and each task object at least includes a task identification field, a task type code field, a task type version field, a general input parameter and a specific input parameter field; The control layer is embedded in the general input parameter and includes a logic parameter field for controlling the execution cycle of the task, and the logic parameter field includes at least one of the number of loop executions, the total execution time and the loop interval of the current task object.

9. The memory chip testing method of claim 8, wherein, The test result is set to have a fixed data format matched with the command issued by the server end, and specifically includes: The fixed data format of the test result report completely contains the fixed data format of the command issued by the server end, and a general output parameter field and a specific output parameter field are added in each task object; The general output parameter field at least includes a result unique identification field, a task execution state field, a client device identification field, a total packet number field and a current packet sequence number field; The specific output parameter field is customized according to the task category defined by the task type code and is used to transmit the configuration information required by the corresponding category task.

10. The memory chip testing method of claim 8, wherein, The method further includes: When the number of loop executions and the total execution time of the current task object are empty or configured as zero values, the corresponding task is executed once; When the number of loop executions or the total execution time of the current task object is configured as a non-zero value, the corresponding task is repeatedly executed until the configuration condition is met; When the number of loop executions and the total execution time are both configured as non-zero values, the corresponding task is repeatedly executed until any configuration condition is met; The loop interval is effective when the task is configured to be executed in a loop.

11. The memory chip testing method of claim 1, wherein, The method further includes: If the communication maintenance instruction is not received within a preset time, the test mode is exited and the debugging mode is entered; and / or After the command issued by the server end is parsed, the method further includes: In response to the server-end issued exit test mode command, the test mode is exited and the debugging mode is entered.

12. A memory chip testing method, characterized by, The memory chip testing method is applied to a server configured with the MQTT protocol, and the method includes: In response to a communication request from an embedded test terminal, a communication hold command is sent to the embedded test terminal at preset time intervals. In response to the command topics pre-subscribed to by the embedded test terminal via the MQTT protocol, test commands are sent to the embedded test terminal; In response to a result topic pre-published by the embedded test terminal via the MQTT protocol, the test results reported by the embedded test terminal are received. The commands issued by the server are set to a preset fixed data format, and the test results reported by the embedded test terminal are set to have a fixed data format that matches the commands issued by the server.

13. The memory chip testing method of claim 12, wherein, The commands issued by the server are set to a fixed data format, specifically including: The fixed data format is configured as a three-layer nested structure including a message layer, a task layer, and a control layer, wherein: The message layer includes at least a command identifier field, a command protocol version field, and a task array field; The task layer is embedded in the task array field and contains at least one task object. Each task object includes at least a task identifier field, a task type code field, a task type version field, a general input parameter field, and a specific input parameter field. The control layer is embedded in the general input parameters and includes a logical parameter field for controlling the task execution loop. The logical parameter field includes at least one of the following: the number of execution loops, the total execution time, and the loop interval.

14. The memory chip testing method of claim 11, wherein, The test results are set to have a fixed data format that matches the commands issued by the server, specifically including: The fixed data format of the test results report fully includes the fixed data format of the commands issued by the server, and adds a general output parameter field and a specific output parameter field to each task object; The general output parameter fields include at least a result unique identifier field, a task execution status field, a client device identifier field, a total package number field, and a current package sequence number field; The specific output parameter field is customized according to the task category defined by the task type code, and is used to convey the specific configuration information required for that category of task.

15. The memory chip testing method of claim 11, wherein, After receiving the test results reported by the embedded test terminal, the process further includes: The test results reported by the embedded test terminal are analyzed. If the result is a test failure, an exit test mode command is sent to the embedded test terminal.

16. A memory chip testing system, comprising: The method includes a server-side and / or at least one embedded test terminal system, the server-side and / or at least one embedded test terminal system including a processor and a memory, the memory being coupled to the processor, the memory being used to store computer program code, the computer program code including computer instructions, and when the processor reads the computer instructions from the memory, the processor causes the processor to execute the steps in the distributed testing method for memory chips as described in any one of claims 1-13.

Images