Chip testing method and device and storage medium

Abstract

The invention discloses a chip test method and device and a storage medium, and the method comprises the steps: controlling a target port to enter a test state when a test for the target port is started; after the target port enters the test state, waiting for a first preset time, and not processing data from the target port within the time; after the first preset time, starting to analyze the data from the target port to detect a preset effective state character; and when the effective state character is detected, sending a chip test instruction to a corresponding lower computer through the target port, and receiving test data fed back by the lower computer. According to the method, invalid data at the initial stage of power-on are effectively filtered by introducing a waiting mechanism, the problems of test false triggering and low efficiency caused by immediate data analysis in the prior art are solved, and the test reliability and the system resource utilization rate are remarkably improved.

Description

Chip testing methods, equipment and storage media Technical Field

[0001] This invention relates to the field of chip testing technology, and in particular to a chip testing method, equipment and storage medium. Background Technology

[0002] In the field of integrated circuit testing, especially in the large-scale aging test of memory chips (such as DRAM and NAND Flash), a distributed test architecture of host computer and slave computer is usually adopted. In this architecture, the host computer acts as the control core of the test system, responsible for the management and control of the test process; the slave computer acts as the test execution unit, responsible for the implementation of specific test operations.

[0003] In existing technologies, the host computer exhibits a significant technical flaw when initiating the test process: once the target slave device port enters the test state, it immediately begins parsing the data stream from that port. However, in the initial power-on phase of the slave device and the chip under test, due to power fluctuations and signal instability during hardware initialization, the data stream often contains a large amount of invalid data or noise. The host computer's immediate parsing of this data can easily lead to misinterpreting noisy data as valid status characters, causing the test process to start incorrectly. Furthermore, processing large amounts of invalid data consumes the host computer's computing resources, reducing system processing efficiency. In addition, test process errors caused by misinterpretations require restarting, further impacting test efficiency. These problems severely restrict the overall efficiency of chip testing systems, especially in large-scale parallel testing scenarios, where this efficiency loss is even more pronounced. Summary of the Invention

[0004] This invention provides a chip testing method, device, and storage medium to solve the problem of low testing efficiency caused by immediately parsing data from the initial stage of testing in the prior art.

[0005] Firstly, a chip testing method is provided, comprising: controlling the target port to enter a test state when starting a test for the target port; waiting for a first preset time after the target port enters the test state, and not processing the data from the target port during this time; after the first preset time, starting to parse the data from the target port to detect a preset valid status character; when a valid status character is detected, sending a chip test command to the corresponding lower-level machine through the target port, and receiving the test data fed back by the lower-level machine.

[0006] Secondly, a host computer is provided, comprising: a test startup module, used to control the target port to enter the test state when starting a test for the target port; a waiting module, used to wait for a first preset time after the target port enters the test state, and not process the data from the target port during this time; a verification module, used to start parsing the data from the target port to detect preset valid status characters after the first preset time; and an instruction issuance and data collection module, used to send a chip test instruction to the corresponding lower-level computer through the target port when a valid status character is detected, and to receive the test data fed back by the lower-level computer.

[0007] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the chip testing method described above.

[0008] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the chip testing method described above.

[0009] The aforementioned chip testing method, apparatus, equipment, and storage medium effectively avoid interference from noise data during the initial power-on phase by introducing a waiting mechanism with a first preset time and refraining from data processing during this period. This mechanism ensures that valid status characters are only parsed after the lower-level machine and the chip under test are fully stable, fundamentally eliminating the possibility of incorrect test process initiation due to misjudgment and significantly improving the reliability of the testing process. Furthermore, the strategy of not processing data within the first preset time effectively reduces the burden on the upper-level machine to process invalid data, allowing system resources to be more concentrated on processing and analyzing valid data. This optimized resource allocation significantly improves the overall operating efficiency of the system, especially in large-scale parallel testing scenarios. Attached Figure Description

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

[0011] Figure 1 is a schematic flowchart of a chip testing method according to an embodiment of the present invention.

[0012] Figure 2 is a flowchart of a chip testing method according to another embodiment of the present invention.

[0013] Figure 3 is a schematic diagram of the structure of the host computer in one embodiment of the present invention.

[0014] Figure 4 is a schematic diagram of the structure of the host computer in another embodiment of the present invention.

[0015] Figure 5 is a structural schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

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

[0017] Please refer to Figure 1, which is a flowchart of a chip testing method provided in an embodiment of the present invention, including the following steps: Step S11: When starting a test for a target port, control the target port to enter the test state.

[0018] Specifically, this step is the initiation action of a single test process. Its purpose is to transition a specific lower-level machine port and its connected chip under test from an idle or ready state to an active state capable of executing test commands. This "test state" is a controlled and stable working state, laying the foundation for subsequent reliable communication handshakes and test execution. The upper-level computer receives the test start command, which may originate from an operator's click on the graphical interface, an automated test script call, or a trigger from an external system. The upper-level computer first parses the command to identify the target port for this test. This target port is a logical identifier that uniquely corresponds to a physical test station through a mapping relationship established during the system initialization phase. For example, "Logical Port 03" corresponds to "Third Test Cabinet - Second Layer - Fifth Station".

[0019] Furthermore, before initiating testing for any target port, a system initialization process must be performed. This stage is fundamental to the normal and efficient operation of the entire testing system. Its core objective is to establish a stable and orderly connection between the host computer and all slave workstations, and to prepare for subsequent precise control and status monitoring. Therefore, based on the above embodiments, other embodiments further include the following before initiating testing for the target port: 1. Powering on multiple slave ports.

[0020] Specifically, the host computer provides unified power to all connected slave devices by controlling a programmable power supply system or intelligent relay array. This is typically not a simple matter of turning on a main switch, but rather a controlled, sequential process. The host computer software sends a set of instructions to the power control module, which includes power-on timing, voltage / current thresholds, soft-start parameters, etc.

[0021] Furthermore, in large-scale systems, to avoid the massive surge currents generated by simultaneously powering on all devices and impacting the power grid and power system, a time-sharing, batch power-on strategy is typically adopted. For example, power can be applied sequentially at intervals of hundreds of milliseconds, according to the rack, level, or functional module. During the power-on process, the host computer monitors the voltage and current data fed back from the power modules in real time. If an abnormality is detected in a power supply (such as overcurrent or undervoltage), the power-on process will be immediately stopped, fault information will be recorded, and an alarm will be triggered, thereby protecting the hardware from damage. This process is entirely software-driven, eliminating the need for manual operation of the power switch, and realizing remote and automated power management of the test system, making unattended testing possible.

[0022] 2. Obtain the location information of multiple lower-level machine ports to construct the mapping relationship between the logical address and physical address of each lower-level machine port.

[0023] Specifically, the host computer actively probes or reads the configuration to obtain the logical address (such as IP address, MAC address, serial bus station number, etc.) of each online slave device by executing the port discovery process. Simultaneously, the system needs to bind each logical address to a physical location (e.g., "Rack A - Frame 3 - Slot 5"). This physical location information can come from a preset configuration file or be directly reported by the slave device in its response message, specifying the location code set by its DIP switch. Finally, the host computer builds and maintains an online port mapping table in memory. The core fields of this table include: logical address, physical location, device model, firmware version, and current status.

[0024] Furthermore, multiple lower-level machines are connected to the upper-level machine via Ethernet; the location information of multiple lower-level machine ports is obtained, including: sending broadcast messages within the local area network or traversing a preset IP address range and receiving response messages from the lower-level machines to dynamically construct an online port list; or, reading a predefined configuration file and locating the lower-level machines based on the IP address, port number, and physical location information listed therein.

[0025] It should be noted that in an Ethernet-based distributed testing system, port location is a core step in system initialization. Its purpose is to quickly and accurately identify all online slave devices in a complex network environment and establish a precise mapping between their network identity (logical address) and physical location. This invention provides two complementary location strategies: dynamic discovery and static configuration.

[0026] Among them, the dynamic discovery method realizes the plug-and-play functionality of the device through active network detection. The specific implementation process includes: (1) The host computer creates a UDP broadcast socket in the local area network and sends a specific "device discovery request" data packet to the restricted broadcast address 255.255.255.255 or the directed broadcast address of the subnet.

[0027] (2) The request packet encapsulates a structured discovery instruction, such as a fixed magic number as a protocol identifier, the host computer's own IP address (for the slave computer to reply), and the instruction type code.

[0028] (3) All online slave devices that support this protocol in the network will parse the request after receiving this broadcast packet on the listening port, and after verification, trigger a response mechanism.

[0029] (4) The lower-level machine will organize a "device discovery response" packet and send it back to the address and port specified by the upper-level machine in the form of unicast. The response packet contains the key identity information of the lower-level machine.

[0030] Dynamic discovery avoids broadcast storms and is more compatible with network devices (such as switches); it can more accurately detect specific addresses and is not affected by interference from unrelated devices. To improve efficiency, the host computer can use multi-threading technology to divide the IP address range into several sub-segments, which are then probed concurrently by different threads, greatly shortening the discovery time for large-scale networks.

[0031] The specific implementation process of static configuration includes: (1) The system administrator prepares a structured configuration file in advance, usually in XML or JSON format, because it has good readability and hierarchical structure.

[0032] (2) When the host computer starts up, or after receiving a command to reload the configuration, it will read and parse the file.

[0033] It should be noted that, in addition to basic address mapping, the configuration file can also contain rich management information, such as: expectedMAC: the expected MAC address. After the host computer discovers the device, it can perform MAC address verification to prevent misidentification due to device replacement or IP conflict.

[0034] stationType: Station type, used to load different test processes.

[0035] calibrationDate: Calibration information used for quality traceability.

[0036] The static configuration method starts up extremely quickly, without waiting for network detection; it completely avoids network broadcasts and message conflicts; it decouples configuration information from the program, so modifying workstation information does not require recompiling or deploying the host computer software.

[0037] Furthermore, in actual deployment, a hybrid strategy can be adopted to balance flexibility and reliability. Specifically: Static configuration is used as the baseline: the system loads the static configuration file by default and builds the desired port mapping table; dynamic discovery is used for verification: the system simultaneously performs a rapid dynamic discovery (such as broadcasting), comparing the list of discovered online devices with the static configuration table. If a device is found that is configured but not online, the workstation is marked as "offline" or "communication interrupted" in the host computer interface, and an alarm is triggered. If a device is found that is online but not recorded in the configuration (i.e., an "unknown device"), it is marked as "unauthorized" and an alarm is triggered, indicating the existence of an unknown node in the network, which may be due to configuration omissions or unauthorized access.

[0038] In this embodiment, by using both dynamic discovery and static configuration, it is possible to adapt to various Ethernet environments from flexible R&D to rigid production, ensuring the efficiency, accuracy and high reliability of the port location process, and laying a solid data foundation for building a stable and transparent automated testing system.

[0039] Furthermore, multiple lower-level machines are connected to the upper-level machine via a serial bus; the location information of multiple lower-level machine ports is obtained, including: starting from the starting address, sending query commands to each preset address in sequence, and receiving responses from the lower-level machines at the corresponding addresses to establish an online port mapping table; or, sending identity reporting commands to the broadcast address on the bus, and receiving the identity information reported by each lower-level machine after a random delay to establish an online port mapping table.

[0040] It is important to understand that port location in distributed test systems based on serial buses (such as RS-485) faces different technical challenges compared to Ethernet environments. Because serial buses typically use half-duplex communication and devices share the communication medium, their location mechanisms require careful protocol design to avoid data collisions and ensure the integrity of the identification. This invention provides two location strategies suitable for serial bus topologies: address-based polling and automatic discovery broadcast mode.

[0041] Among them, the address-based polling method is suitable for stable production environments where the bus device addresses are known and fixed, providing a reliable and orderly device discovery method. The specific implementation process includes: (1) Preset address space: The system defines a complete address space (e.g., 1 to 247, following industry standards such as Modbus). Each lower-level machine is assigned a unique station number in this space through hardware DIP switches, jumpers, or by burning it into non-volatile memory.

[0042] (2) Sequential query: Starting from the starting address (e.g., address 1), the host computer sends a dedicated query instruction to each possible address in sequence. This instruction is framed strictly according to the bus communication protocol.

[0043] (3) Response and Timeout Handling: After sending each query command, the host computer starts a response timeout timer (e.g., set to 200 milliseconds). Only target slave devices with completely matching addresses will process the command and reply with a response frame containing their own identity information. Slave devices with non-target addresses will ignore the command.

[0044] (4) Mapping table construction: The host computer gradually fills the online port mapping table in memory based on the received responses. For addresses that do not receive a response within the timeout period, the host computer marks them as "not found" or "offline" and then continues to query the next address.

[0045] The address-based polling method is simple to implement, highly reliable, and completely avoids message conflicts caused by multiple devices responding simultaneously.

[0046] Automatic discovery broadcast mode is suitable for scenarios where the device address is unknown or where it is necessary to quickly discover online devices. It improves efficiency through a controlled competition mechanism. The specific implementation process includes: (1) Broadcast query: The host computer sends an "identity report" instruction to the broadcast address on the bus (usually address 0 or 255, depending on the protocol definition). All slave computers on the bus can receive the instruction.

[0047] (2) Random delay reporting: This is the core mechanism to avoid conflicts. Each lower-level machine that receives the broadcast does not reply immediately, but generates a random delay value independently. This random value is usually within a set window (e.g., 10 milliseconds to 500 milliseconds).

[0048] (3) Conflict detection and handling: After sending a broadcast, the host computer will listen to the bus. Due to the existence of random delay, the responses of each slave computer are distributed in time, thus avoiding conflicts with a high probability. However, when there are many devices and the random range is small, conflicts may still occur.

[0049] (4) Conflict detection: The host computer determines that a conflict has occurred by detecting malformed data frames that cannot pass the CRC check.

[0050] (5) Backoff algorithm: Once a conflict is detected, the host computer waits for a period of silence before initiating a new round of broadcast discovery process. At the same time, it can dynamically adjust the window size of the random delay, or carry a "discovery round number" in the instruction to guide the slave computer to use a more complex algorithm (such as binary exponential backoff) to recalculate the delay, thereby reducing the probability of another conflict.

[0051] (6) Mapping table construction: Within the preset total discovery time window (e.g., 2 seconds), the host computer collects all successfully received, conflict-free response frames and constructs an online port mapping table accordingly.

[0052] Furthermore, in practical deployments, the advantages of both methods can be combined: First, a broadcast mode is used for rapid scanning, establishing a preliminary list of online devices within tens of milliseconds to several seconds. Then, for devices in this list, precise address polling is used to communicate again, verifying the accuracy of their identity information and performing more detailed parameter readings. This hybrid strategy balances speed and reliability.

[0053] In this embodiment, the use of both address-based polling and automatic discovery broadcast modes allows for flexible adaptation to serial bus testing environments of different scales and requirements.

[0054] Furthermore, after obtaining the location information of multiple lower-level ports, the method also includes configuring an independent display area for each located port to display test status information in real time.

[0055] Specifically, after successfully acquiring the location information of all lower-level machine ports and establishing a logical-physical address mapping table, the system achieves visual monitoring of the test system status by configuring an independent display area for each located port. This is a key step in transforming the underlying hardware status into upper-level human-computer interaction information, which greatly improves the observability and operability of the system.

[0056] The display area can be dynamically generated. After completing port location, the host computer software immediately traverses the online port mapping table maintained in memory. For each valid port in the table, the host computer's user interface management module dynamically creates an independent graphical display component. This process is automated, requiring no manual dragging or configuration, ensuring real-time consistency between the interface and the physical system structure. These display components are typically arranged in a grid or list layout on the main monitoring interface. Their arrangement order can strictly correspond to physical locations (e.g., "Rack A -> Shelf 1 -> Workstation 1, 2, 3..."), helping operators quickly establish an intuitive mapping between screen location and workshop location. The interface also supports grouping and filtering; for example, display areas can be grouped and shown or hidden by rack, test item, or equipment model, allowing operators to focus on the currently relevant parts among a large number of workstations. Each independent display area is an information complex, presenting the comprehensive status of the corresponding port in real time through various UI elements. The core display elements include: Port identification and connection status: clearly displaying the port's logical address and physical location, and visually indicating the port's online / offline status through a status indicator light. For example, solid green indicates online and idle, while red indicates communication interruption or failure.

[0057] Test status and progress: The current test stage is dynamically displayed through status labels, such as "Idle", "Initialization", "Testing", "Pass", and "Failed". The progress bar intuitively displays the completion percentage of long-term test tasks, allowing operators to have a clear understanding of the test progress.

[0058] Key parameters and yield statistics: Real-time display of core measurement values ​​for the current test cycle, such as voltage, current, frequency, timing parameters, etc., dynamically calculates and displays the real-time yield of the port in the format of number of passes / total number of tests, providing immediate feedback on production quality.

[0059] Step S12: After the target port enters the test state, wait for the first preset time and do not process the data from the target port during this time.

[0060] Specifically, the purpose of this step is to proactively avoid signal noise generated by the lower-level machine and the chip under test during the power-on initialization phase by introducing a controlled "communication stability window," thereby ensuring the accuracy and efficiency of subsequent data parsing. Ignoring data from the target port is not simply discarding it, but a systematic and configurable suppression strategy. This strategy can be implemented in various ways at the software and hardware levels, such as: driver-level suppression: the host computer issues instructions to the underlying serial port or network communication driver, causing it to suspend the transmission of received raw byte data to the upper application layer for a specific time period after T0. The data may be directly overwritten in the hardware buffer, thus achieving physical "ignoring."

[0061] Application-layer filtering: At time T0, the upper-layer application sets a data receive enable flag (DataReceiveEnableFlag) associated with the target port to False. Although the application's data receive thread continuously reads the communication buffer, it checks this flag before processing each data packet. If the flag is False, the thread will actively skip the parsing, verification, and business logic processing of data for that port.

[0062] Buffer clearing: At the end of the first preset time, the host computer can perform a clearing operation on the communication buffer of this port to ensure that no residual initialization data is mixed into the subsequent valid data stream.

[0063] It should be noted that the first preset time is not a fixed value, but a configurable parameter based on system characteristics. Its setting is mainly based on the following factors: the startup time of the lower-level machine: the time taken from power-on to the core program starting stable operation.

[0064] Initialization time of the chip under test: the entire process from chip reset, firmware loading, clock stabilization, completion of self-test (POST) until other communication interfaces begin to output stable and standardized data streams.

[0065] Power supply stabilization time: The time required for the supply voltage / current to reach a stable state within the rated ripple specification after startup.

[0066] Safety margin: Add a margin (e.g., 10-20%) to the theoretical maximum time to cope with fluctuations caused by component aging, changes in ambient temperature, etc.

[0067] The first preset time value is stored in the host computer's configuration file or database and is strongly correlated with the model of the chip under test or the test item. For example, for a simple NOR Flash chip that boots quickly, the first preset time can be configured to 3 seconds; for a SoC (System-on-a-Chip) with a complex boot process that requires loading a large amount of firmware, the first preset time may need to be configured to 10 seconds or even 15 seconds. In advanced implementations, the system can dynamically fine-tune the first preset time based on historical data. For example, if the system frequently detects the status character for the first time at the end of the first preset time, it indicates that the setting is relatively accurate; if it always waits for much longer than the actual ready time, the first preset time can be appropriately reduced to improve efficiency.

[0068] Step S13: After the first preset time, start parsing the data from the target port to detect the preset valid status characters.

[0069] Specifically, this step marks the system's transition from the communication stability window to the active detection phase, a crucial step in determining whether the lower-level machine and the chip under test have completed initialization and entered a testable state. Its core task is to accurately identify valid status characters representing system readiness from the data stream according to a predetermined communication protocol. This process specifically includes: I. Protocol Parsing and Data Extraction: 1. Activation of the Communication Protocol Stack: After the first preset time arrives, the upper-level machine performs the following sequence of operations: setting the data receive enable flag of the corresponding target port to True, and activating the dedicated data parsing thread or task for that port.

[0070] 2. Data Frame Deconstruction and Verification: The parsing process strictly follows the preset communication protocol, specifically including: Frame Synchronization: The parser scans specific frame start symbols in the raw byte stream to locate the start position of a complete data frame; Data Extraction: Based on the frame structure defined by the protocol, the parser extracts key fields, including: destination address, data length, payload, checksum, and integrity check. Only data frames that pass verification are considered valid, and their payloads are submitted to the subsequent status character matching module. Frames that fail verification are recorded in the error log and discarded.

[0071] II. Status Character Matching Mechanism: 1. Matching Strategy: After extracting the data content from the payload, the system performs an exact match against valid status characters pre-stored in memory or configuration files. Exact string matching is the most basic matching method. For example, if the status character is defined as "DUT_READY_v1.0", then a match is considered successful only if the received data content is completely identical to this string.

[0072] 2. Matching Engine Implementation: Matching operations are performed within a dedicated, efficient matching engine. For simple exact matches, standard string comparison functions can be used. For complex regular expressions, efficient regular expression libraries (such as PCRE) can be integrated. The matching process is typically designed to be case-sensitive to further improve accuracy and avoid false matches.

[0073] Furthermore, after step S13, the method further includes: if no valid status character is detected after a second preset time, then mark the target port communication as abnormal and trigger a reconnection mechanism or issue an alarm message.

[0074] Specifically, this step is a crucial component of the handshake mechanism, forming the last line of defense for communication reliability. When the system fails to complete the handshake successfully within the expected timeframe, this mechanism ensures that the fault is promptly captured, diagnosed, and handled, preventing the system from waiting indefinitely or entering an unknown state, thus guaranteeing the automation and continuity of the testing process. The starting point for the second preset time is the same as the first preset time, which is the moment the port enters the test state. The duration of the second preset time must be greater than the first preset time. Its total duration covers both the first preset time and the second preset time minus the first preset time. Once a communication anomaly is confirmed, the system will automatically execute a standardized processing procedure: 1. Port Status Marking: The system immediately updates the status of the target port to "communication anomaly" in the online port mapping table in memory. On the visual monitoring interface, the display area corresponding to this port will trigger a visual alarm, such as the status indicator light turning red and flashing, while the specific error code (e.g., "ERR_COMM_TIMEOUT") is displayed in the status information bar.

[0075] 2. Triggering the Reconnection Mechanism: The reconnection mechanism aims to attempt to automatically restore communication. Its core is a configurable retry strategy: (a) Number of retries and interval: The system allows preset maximum number of retries (e.g., 3 times) and retry interval. An advanced strategy is to use an exponential backoff algorithm, that is, the waiting interval for each retry is gradually extended (e.g., 5 seconds for the first time, 10 seconds for the second time, and 20 seconds for the third time). This avoids wasting resources by continuously and rapidly retrying on permanent faults and also provides sufficient time for instantaneous network recovery. (b) Resetting the connection: Each retry is not simply resending the query command, but executing a complete "reset-rebuild" cycle. The host computer first controls the slave computer or the chip under test to perform a soft reset through the command, and then resets the state machine of the port to the initial state, and re-executes the complete test startup process starting from step S1, including controlling the port to enter the test state, waiting for the first preset time, and detecting the status character. (c) Termination condition: If it is still unsuccessful after reaching the maximum number of retries, the system will stop automatic retrying and update the port status to "serious fault, manual intervention required".

[0076] 3. Issue alarm information: The alarm system ensures that the fault can be detected and handled by relevant personnel in a timely manner. It adopts a multi-level and multi-channel strategy.

[0077] This anomaly handling procedure transforms communication failures that could cause system shutdowns into a standardized process that is manageable, automatically recoverable, and traceable. Through precise timeout determination, intelligent retry strategies, and tiered alarm notifications, it constructs a complete fault handling closed loop, significantly improving the robustness, automation, and maintainability of the testing system. It is a key technological guarantee for realizing an unattended, intelligent testing factory.

[0078] Step S14: When a valid status character is detected, a chip test command is sent to the corresponding lower-level machine through the target port, and the test data fed back by the lower-level machine is received.

[0079] Specifically, this step marks the formal transition of the testing process from the preparation phase to the execution phase. After successfully completing a reliable handshake mechanism, the host computer begins substantive test interactions with the slave computer, the core of which lies in the accurate issuance of test commands and the complete retrieval of test data.

[0080] When the status character matches successfully, the host computer's test engine will construct specific chip test instructions according to the preset test plan. The assembly of these instructions strictly follows the communication protocol specifications.

[0081] Frame structure example: Frame header: 2 bytes, fixed at 0xAA55, used for frame synchronization.

[0082] Target address: 1 byte, specifies the address of the lower-level machine receiving the instruction, ensuring accurate delivery of the instruction.

[0083] Instruction code: 1 byte, defines the test type. For example: 0x01: start functional test, 0x02: start parameter measurement (such as voltage, current), 0x03: start aging stress test.

[0084] Data field / parameter field: Variable length, containing specific parameters required for the test. For example, when performing a frequency test, this field can contain the target frequency value; when performing a voltage scan test, it can contain the start voltage, end voltage, and step value.

[0085] Checksum: 2 bytes, using the CRC-16 algorithm, covering all content from the frame header to the data field, ensuring the integrity of the instruction during transmission.

[0086] Frame end: 2 bytes, fixed at 0x0D0A, indicating the end of the frame.

[0087] The encapsulated instruction frame is sent to the target lower-level machine through the corresponding physical port (Ethernet or serial port). Upon receiving the instruction, the lower-level machine performs verification. If verification succeeds, it replies with an ACK message; if verification fails or the instruction cannot be executed, it replies with a NAK message along with an error code. The upper-level machine starts an acknowledgment timeout timer after sending the instruction. Only after receiving an ACK or processing a NAK is the instruction considered successfully sent, and subsequent processes continue.

[0088] After confirming the test command, the lower-level machine drives the chip under test to perform the corresponding test operations and monitors its response in real time. The test result data is encapsulated into data frames by the lower-level machine and fed back to the upper-level machine according to a preset period or event trigger. The upper-level machine continuously listens to the target port and receives the data stream from the lower-level machine. The received raw data stream is sent to the protocol parsing engine for frame de-framing, verification, and payload extraction. The payload contains the structured test results.

[0089] Furthermore, the test data includes test information logs and test command logs. The test information logs contain structured test result data, and the test command logs record all instructions that interact with the lower-level machine in chronological order.

[0090] Specifically, the test information log focuses on recording the essential results of the tests, and its design goal is to serve quality analysis and production traceability. Each test information log record is a structured data unit, such as: timestamp, port number, chip ID, test item 1, result 1, measurement value 1, test item 2, result 2, etc. The host computer generates an independent test information log file (such as CSV or XML format) for each chip, or directly stores it in a database for subsequent yield analysis and data traceability.

[0091] The test command log focuses on recording the control process of the test, and its design goal is to serve communication debugging and process reproduction. The test command log faithfully records all uplink (TX, issued by the host computer) and downlink (RX, received by the host computer) raw commands or their key summaries. It uses plain text format and has extremely high readability. For example: all uplink and downlink commands are recorded in chronological order, [2023-10-27 10:30:05] [TX]TO 01: START_TEST_1, [2023-10-27 10:30:06][RX]FROM 01: TEST_1_PASS.

[0092] In this embodiment, a comprehensive data recording system is constructed by implementing a dual-log system that includes both test information logs and test command logs. This system not only provides a solid data foundation for production quality analysis and yield improvement, but also provides powerful tools for the system's own debugging, maintenance, and optimization. It is a key design for achieving high reliability and maintainability of the test system.

[0093] This embodiment effectively avoids interference from noise data during the initial power-on phase of the test process by introducing a waiting mechanism with a first preset time and refraining from data processing during this period. This mechanism ensures that valid status characters are only parsed after the lower-level machine and the chip under test are fully stable, fundamentally eliminating the possibility of test process mis-start due to misjudgment and significantly improving the reliability of the test process. Moreover, by not processing data within the first preset time, the burden of processing invalid data on the upper-level machine is effectively reduced, allowing system resources to be more concentrated on the processing and analysis of valid data. This resource optimization significantly improves the overall operating efficiency of the system, especially in large-scale parallel testing scenarios.

[0094] Furthermore, in large-scale distributed testing systems, when the lower-level machine testing logic needs to be upgraded or repaired, the traditional method of manually updating firmware one by one leads to long-term downtime of the testing system, severely impacting the overall efficiency of the testing production line. Simultaneously, due to the difficulty in ensuring version consistency across all lower-level machine testing firmware, different testing stations may execute different testing standards, resulting in unreliable test results and distorted yield analysis. To achieve the above objectives, based on the above embodiments, in other embodiments, as shown in Figure 2, the chip testing method further includes: Step S21: Obtaining the new version firmware file and the list of lower-level machines to be updated.

[0095] Specifically, this step is the initialization phase of the update task, designed to prepare all digital assets and target objects for batch updates. The host computer loads the new firmware file (e.g., firmware_v2.1.5.bin) from a specified storage location (such as a local hard drive, network shared directory, or version control system). During loading, the host computer performs integrity checks on the firmware file, such as calculating its MD5 or SHA-256 hash value and comparing it with preset standard values ​​to ensure that the file has not been corrupted during transmission or storage. The list of slave devices to be updated can be dynamically generated or statically specified in various ways. For example, the list can include all online slave devices in the system, or the targets can be filtered based on the slave device's hardware version, current firmware version, or its physical location group (such as a specific rack), or the administrator can manually select the specific workstations to be updated through the host computer interface.

[0096] Step S22: Traverse the list of lower-level machines and create and start an update management instance for each lower-level machine in the list.

[0097] Specifically, the host computer employs a multi-threaded programming model, creating an independent update management instance for each slave device in the list. Each instance is an independent execution unit that encapsulates complete update logic.

[0098] Each update management instance is configured to perform the following: 1. Call the firmware transfer method to send the new version firmware file to the corresponding lower-level machine through the corresponding port.

[0099] Specifically, the host computer divides the firmware file into multiple fixed-size data packets and assigns each packet a consecutive sequence number. It uses a sliding window mechanism for transmission, meaning it can continuously send multiple data packets within a window size before receiving an acknowledgment, thus fully utilizing bandwidth. The slave computer verifies each received data packet (e.g., CRC32) and notifies the host computer by sending an acknowledgment packet. If the host computer detects packet loss or a verification error (via timeout or NAK message), it automatically retransmits the data packet. This mechanism ensures data integrity and correctness on unreliable communication channels (such as long-distance RS-485 buses). After the entire firmware file is transmitted, the slave computer's bootloader performs a final verification (e.g., CRC32 or SHA-1) on the received firmware image. If the verification passes, the new firmware is written to the program storage area (Flash), and boot flag 2 is set. The running status of all update management instances is monitored.

[0100] Specifically, a central update monitoring coordinator is responsible for overall status control. Each update management instance periodically reports its status to the coordinator, such as "Transmitting (25%)", "Waiting for confirmation", "Verification in progress", "Success", and "Failure". The coordinator aggregates the status of all instances and reflects it in real time on the user interface. Operators can view the update progress of all workstations on a single dashboard, seeing the number of successful updates, the number of failed updates, and the number in progress.

[0101] 3. When any update management instance is detected to be in an abnormal state due to communication timeout or verification error, the exception is captured and the corresponding lower-level machine information is recorded in the update failure list.

[0102] Specifically, each update management instance has a robust exception handling mechanism. When communication timeouts (long periods without response), checksum errors (receiving a NAK or checksum mismatch), or command execution failures occur, the instance catches these exceptions instead of causing the entire program to crash. After catching an exception, the instance marks its own status as "failed" and adds the target lower-level machine's identifier (such as physical location, logical address) and the error reason (such as "communication timeout" or "205 packet checksum failure") to a globally shared update failure list.

[0103] 4. Re-initiate the update process based on the list of failed updates.

[0104] Specifically, after the main process of the batch update task is completed, the system will check the update failure list. For the lower-level machines on the list, the system will not give up immediately, but will automatically re-initiate the update process.

[0105] Furthermore, retries are not performed immediately, but rather after a short delay (e.g., 30 seconds), which helps avoid momentary network congestion or busy conditions on the lower-level device. The system sets a retry counter for each failed lower-level device. If the maximum number of retries (e.g., 3) is exceeded without success, the system will stop retries, permanently mark it as "update failed," and generate a critical alarm requiring manual intervention. For repeatedly failing lower-level devices, they can be temporarily "isolated" in subsequent rounds of a batch update task to prevent their individual problems from affecting the retry efficiency of other normal devices.

[0106] It is important to understand that, in this embodiment, the test information logs and test command logs generated during the core testing process provide a data foundation for optimizing the lower-level firmware. By analyzing test failure cases or performance bottlenecks, engineers can pinpoint defects in the test algorithms or parameter processing within the firmware, thereby developing improved new firmware versions. The batch update function deploys the optimized firmware to all lower-level machines before the start of a new round of testing or within the system's preset maintenance window. This process ensures that when the testing process restarts, the test logic executed by all lower-level machines is up-to-date and consistent. The firmware-updated testing system performs subsequent chip tests with higher reliability and accuracy, generating higher-quality test data, which in turn provides input for the next round of firmware optimization. Therefore, firmware updates are not an independent function, but a key technological link connecting the current test with the next, driving the continuous iterative evolution of the entire testing system. Together with the core testing process, it forms a complete technical closed loop of test-analysis-update-retest, jointly committed to improving the long-term efficiency and reliability of the testing system.

[0107] This embodiment uses parallel processing of multiple instances to compress the serial update work that originally took several hours to complete within a few minutes, greatly shortening the system maintenance window and making it possible to remotely and in batches maintain hundreds or thousands of distributed lower-level machines. This achieves automation and intelligence in operation and maintenance work and significantly reduces labor costs.

[0108] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0109] In one embodiment, a host computer is provided, which corresponds one-to-one with the chip testing method in the above embodiments. As shown in Figure 4, the host computer includes a test startup module 11, a waiting module 12, a verification module 13, and an instruction issuance and data collection module 14.

[0110] The test initiation module 11 is used to control the target port to enter the test state when starting a test for the target port; the waiting module 12 is used to wait for a first preset time after the target port enters the test state, and during this time, the data from the target port is not processed; the verification module 13 is used to start parsing the data from the target port to detect preset valid status characters after the first preset time; the instruction issuance and data collection module 14 is used to send a chip test instruction to the corresponding lower-level machine through the target port when a valid status character is detected, and to receive the test data fed back by the lower-level machine.

[0111] Optionally, before performing the operation of starting the test for the target port, the test startup module 11 is also used to: power on multiple lower-level ports; obtain the location information of multiple lower-level ports to construct the mapping relationship between the logical address and the physical address of each lower-level port.

[0112] Optionally, multiple lower-level machines are connected to the upper-level machine via Ethernet; the test startup module 11 performs the operation of obtaining the location information of multiple lower-level machine ports, specifically including: sending broadcast messages in the local area network or traversing a preset IP address range and receiving response messages from the lower-level machines to dynamically construct an online port list; or, reading a predefined configuration file and locating the lower-level machines according to the IP address, port number and physical location information of each lower-level machine listed therein.

[0113] Optionally, multiple lower-level machines are connected to the upper-level machine via a serial bus; the test startup module 11 performs the operation of obtaining the positioning information of multiple lower-level machine ports, specifically including: starting from the starting address, sending query instructions to each preset address in sequence, and receiving the response from the lower-level machine at the corresponding address to establish an online port mapping table; or, sending an identity reporting instruction to the broadcast address on the bus, and receiving the identity information reported by each lower-level machine after a random delay to establish an online port mapping table.

[0114] Optionally, after the test startup module 11 performs the operation of obtaining the location information of multiple lower-level machine ports, it is also used to: configure an independent display area for each located port to display test status information in real time.

[0115] Optionally, after the waiting module 12 performs the operation of starting to parse data from the target port to detect a preset valid status character, it is also used to: if no valid status character is detected after a second preset time, mark the target port communication as abnormal and trigger a reconnection mechanism or issue an alarm message.

[0116] Optionally, the test data includes test information logs and test command logs. The test information logs contain structured test result data, and the test command logs record all instructions interacting with the lower-level machine in chronological order.

[0117] Optionally, as shown in Figure 4, the host computer further includes: an acquisition module 21, used to acquire the new version firmware file and a list of lower-level machines to be updated; and a creation module 22, used to traverse the list of lower-level machines, create and start an update management instance for each lower-level machine in the list; wherein each update management instance is configured to perform: calling the firmware transmission method to send the new version firmware file to the corresponding lower-level machine through the corresponding port; monitoring the running status of all update management instances; when any update management instance is detected to be in an abnormal state due to communication timeout or verification error, capturing the exception and recording the corresponding lower-level machine information to the update failure list; and re-initiating the update process according to the update failure list.

[0118] For specific limitations regarding the host computer, please refer to the limitations of the chip testing method mentioned above, which will not be repeated here. Each module in the aforementioned host computer can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the computer device in hardware form or independent of it, or they can be stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0119] In one embodiment, a computer device is provided, the internal structure of which can be shown in Figure 5. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it performs the following steps: upon initiating a test for a target port, controlling the target port to enter a test state; after the target port enters the test state, waiting for a first preset time, and during this time, not processing data from the target port; after the first preset time, starting to parse data from the target port to detect preset valid status characters; when a valid status character is detected, sending a chip test command to the corresponding lower-level machine through the target port, and receiving test data fed back by the lower-level machine.

[0120] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, it performs the following steps: when a test is initiated for a target port, the target port is controlled to enter a test state; after the target port enters the test state, a first preset time is waited for, and during this time, no data from the target port is processed; after the first preset time, the data from the target port is parsed to detect a preset valid status character; when a valid status character is detected, a chip test command is sent to the corresponding lower-level machine through the target port, and test data fed back by the lower-level machine is received.

[0121] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0122] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other storage media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0123] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0124] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A chip testing method, characterized in that, The method, applied to a host computer, includes: when initiating a test for a target port, controlling the target port to enter a test state; after the target port enters the test state, waiting for a first preset time, and not processing the data from the target port during this time; after the first preset time, starting to parse the data from the target port to detect a preset valid status character; when the valid status character is detected, sending a chip test command to the corresponding lower-level computer through the target port, and receiving the test data fed back by the lower-level computer.

2. The chip testing method according to claim 1, characterized in that, Before initiating the test for the target port, the process also includes: powering on multiple lower-level ports; obtaining the location information of the multiple lower-level ports to construct a mapping relationship between the logical address and the physical address of each lower-level port.

3. The chip testing method according to claim 2, characterized in that, The plurality of lower-level machines are connected to the upper-level machine via Ethernet; obtaining the location information of the ports of the plurality of lower-level machines includes: sending broadcast messages in the local area network or traversing a preset IP address range and receiving response messages from the lower-level machines to dynamically construct an online port list; or, reading a predefined configuration file and locating the lower-level machines according to the IP address, port number and physical location information of each lower-level machine listed therein.

4. The chip testing method according to claim 2, characterized in that, The plurality of lower-level machines are connected to the upper-level machine via a serial bus; the step of obtaining the location information of the ports of the plurality of lower-level machines includes: starting from a starting address, sequentially sending a query command to each preset address, and receiving the response from the lower-level machine at the corresponding address to establish an online port mapping table; or, sending an identity reporting command to the broadcast address on the bus, and receiving the identity information reported by each lower-level machine after a random delay to establish an online port mapping table.

5. The chip testing method according to claim 2, characterized in that, After obtaining the location information of the multiple lower-level machine ports, the method further includes: configuring an independent display area for each located port to display test status information in real time.

6. The chip testing method according to claim 1, characterized in that, After the step of parsing data from the target port to detect a preset valid status character, the method further includes: if the valid status character is not detected after a second preset time, then the target port is marked as having a communication error, and a reconnection mechanism is triggered or an alarm message is issued.

7. The chip testing method according to claim 1, characterized in that, The test data includes test information logs and test command logs. The test information logs contain structured test result data, and the test command logs record all instructions interacting with the lower-level machine in chronological order.

8. The chip testing method according to claim 1, characterized in that, The method further includes: obtaining a new version firmware file and a list of lower-level devices to be updated; traversing the list of lower-level devices, creating and starting an update management instance for each lower-level device in the list; wherein each update management instance is configured to perform: calling a firmware transmission method to send the new version firmware file to the corresponding lower-level device through the corresponding port; monitoring the running status of all update management instances; when any update management instance is found to be in an abnormal state due to communication timeout or verification error, capturing the abnormality and recording the corresponding lower-level device information in the update failure list; and re-initiating the update process according to the update failure list.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the chip testing method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the chip testing method as described in any one of claims 1 to 8.

Images