Test breakpoint control method and system for ATE diagnosis process

Abstract

The invention belongs to the technical field of ATE diagnosis, particularly relates to a test breakpoint control method and system for an ATE diagnosis process, and is used for solving the problems that existing ATE diagnosis breakpoint control depends on software codes, the operation threshold is high, hardware identifiers cannot be accurately associated, and the fault positioning efficiency is low. The method comprises the following steps: configuring breakpoint parameters, wherein the breakpoint parameters comprise identification information and trigger conditions of a target hardware unit; loading the breakpoint parameter into a test flow of an ATE diagnosis process; in the process of executing the test process, contextual information of a currently tested hardware unit is obtained in real time, and the contextual information comprises an identifier of the current hardware unit; matching the identifier of the current hardware unit with the identifier information of the target hardware unit, and if the identifier information of the current hardware unit is consistent with the identifier information of the target hardware unit and meets the trigger condition, triggering interruption to suspend the current test process; and in response to a recovery instruction, releasing the interruption and continuing to execute the test process.

Description

Technical Field

[0001] This invention belongs to the field of ATE diagnostic technology, specifically relating to a test breakpoint control method and system for the ATE diagnostic process. Background Technology

[0002] In the electronics manufacturing industry, Automated Test Equipment (ATE) is a crucial component in the hardware product manufacturing process. It is widely used for functional testing and fault diagnosis of hardware units such as single boards and modules. Through automated testing processes, it enables rapid verification of various performance indicators of hardware units, directly impacting product manufacturing efficiency and quality control. To ensure timely problem location when anomalies occur during testing, ATE diagnostic systems typically need breakpoint control functionality. This involves pre-setting interruption points in the testing process to pause testing under specific conditions while preserving the current state, providing a basis for troubleshooting.

[0003] However, existing breakpoint control methods in ATE diagnostic processes largely rely on software-level instructions or code logic to set breakpoints, such as using line numbers, function names, or specific variable values ​​in the test program as trigger conditions. This approach has significant limitations: firstly, the configuration of breakpoint parameters is disconnected from the physical properties of the hardware unit, requiring operators to be familiar with the code structure of the test program to set effective breakpoints, posing a high operational barrier for hardware testing specialists; secondly, because it doesn't directly link to the identification information of the target hardware unit, when the test process involves multiple hardware units (such as different channels, interfaces, or modules), it's difficult to accurately trigger interruptions for specific hardware units, easily leading to false or missed breakpoint triggers and low fault location efficiency. Furthermore, existing methods lack flexibility in post-interruption recovery mechanisms, often requiring a restart of the entire test process, affecting test continuity and equipment utilization, and failing to meet the needs of efficient diagnostics in large-scale production.

[0004] Therefore, how to achieve precise breakpoint control based on hardware unit identification, reduce the operational threshold, and improve the efficiency of test interruption and recovery has become an urgent problem to be solved in the field of ATE diagnostic technology. Summary of the Invention

[0005] The purpose of this invention is to provide a test breakpoint control method and system for the ATE diagnostic process, so as to solve the above-mentioned problems.

[0006] To achieve the above objectives, in a first aspect of the present invention, a test breakpoint control method for the ATE diagnostic process is provided, comprising the following steps: Configure breakpoint parameters, which include the identification information of the target hardware unit and the triggering conditions; The breakpoint parameters are loaded into the test flow of the ATE diagnostic process; During the execution of the test process, the context information of the hardware unit currently being tested is obtained in real time, and the context information includes the identifier of the current hardware unit; The identifier of the current hardware unit is matched with the identifier information of the target hardware unit. If the match is consistent and the triggering condition is met, an interrupt is triggered to pause the current test process. In response to the recovery command, the interruption is lifted and the test process continues.

[0007] Furthermore, in the test breakpoint control method for the ATE diagnostic process, the identification information of the target hardware unit includes at least one of the board identifier, channel identifier, and test item name of the device under test during the ATE diagnostic process.

[0008] Furthermore, in the test breakpoint control method for the ATE diagnostic process, the triggering condition includes at least one of the following: triggering when the test process enters the test phase of the target hardware unit, triggering when the test result of the target hardware unit is a failure, and triggering under the global test enabled state.

[0009] Furthermore, in the test breakpoint control method for the ATE diagnostic process, the step of triggering the interrupt further includes: saving the hardware status data of the device under test and the running data of the test process at the time of the interruption, wherein the hardware status data includes the physical parameters of the target hardware unit.

[0010] Furthermore, in the test breakpoint control method for the ATE diagnostic process, before responding to the recovery command, the method further includes: displaying the identification information of the target hardware unit and the reason for the interruption through an interactive interface, and receiving input operation commands.

[0011] In a second aspect of the invention, a test breakpoint control system for the ATE diagnostic process is also provided, comprising a configuration module, a loading module, a tracking module, a matching and interruption module, and an interaction and recovery module: The configuration module is used to receive input breakpoint parameters, which include the identification information of the target hardware unit and the triggering conditions. The loading module is used to load the breakpoint parameters into the test flow during the ATE diagnostic process; The tracking module is used to obtain the context information of the hardware unit currently being tested in real time during the execution of the test process. The context information includes the identifier of the current hardware unit. The matching and interruption module is used to match the identifier of the current hardware unit with the identifier information of the target hardware unit. If the match is consistent and the triggering condition is met, an interruption is triggered to pause the current test process. The interaction and recovery module is used to respond to the recovery command, release the interruption, and control the test process to continue execution.

[0012] Furthermore, in the test breakpoint control system for the ATE diagnostic process, the configuration module supports inputting the identification information of the target hardware unit through a visual interface. The identification information includes at least one of the following: the board identifier of the device under test, the hardware channel identifier, and the test item name during the ATE diagnostic process.

[0013] Furthermore, in the test breakpoint control system for the ATE diagnostic process, the matching and interruption module also includes a status saving unit, which is used to save the hardware status data of the device under test and the running data of the test process at the time of the interruption when an interruption is triggered.

[0014] Furthermore, in the test breakpoint control system for the ATE diagnostic process, the interaction and recovery module includes a display unit and an instruction receiving unit; the display unit is used to display the identification information and interruption reason of the target hardware unit; the instruction receiving unit is used to receive input recovery instructions or debugging instructions.

[0015] Furthermore, in the test breakpoint control system for the ATE diagnostic process, the triggering conditions include at least one of the following: triggering when the test process enters the test phase of the target hardware unit, triggering when the test result of the target hardware unit is a failure, and triggering under the global test enabled state.

[0016] Compared with the prior art, the present invention has at least the following technical effects: The test breakpoint control method of this invention configures breakpoint parameters including target hardware unit identification information and trigger conditions, and loads them into the test process. During the test, it obtains the current hardware unit context information in real time and matches it with the target identifier. When the conditions are met, an interrupt is triggered, the test process is paused, and a recovery command is responded to continue execution. This not only enables precise breakpoint control based on hardware entities without the need for deep involvement of developers, reducing the operational threshold for maintenance personnel, but also quickly captures the test fault scene, significantly shortening the problem location and analysis cycle. At the same time, it does not rely on external tools and has strong environmental adaptability, thereby effectively improving the flexibility and efficiency of ATE diagnostics and the utilization rate of production line equipment. Attached Figure Description

[0017] Figure 1 This is a flowchart of a test breakpoint control method for the ATE diagnostic process in one embodiment of the present invention; Figure 2 This is a framework diagram of a test breakpoint control system for the ATE diagnostic process in one embodiment of the present invention. Detailed Implementation

[0018] The following will describe in more detail a test breakpoint control method and system for ATE diagnostic processes according to the present invention, with reference to schematic diagrams, which illustrate preferred embodiments of the invention. It should be understood that those skilled in the art can modify the invention described herein while still achieving its advantageous effects. Therefore, the following description should be understood as being of general knowledge to those skilled in the art and is not intended to limit the invention.

[0019] For clarity, not all features of the actual embodiments are described. In the following description, well-known functions and structures are not detailed in detail, as they would obscure the invention with unnecessary detail. It should be understood that in the development of any actual embodiment, numerous implementation details must be made to achieve the developer's specific objectives, such as changes from one embodiment to another according to limitations related to the system or business. Furthermore, it should be understood that such development work may be complex and time-consuming, but is merely routine work for those skilled in the art.

[0020] Based on the teachings of this specification, those skilled in the art can form new technical solutions through cross-combination of different implementation methods without creating technical contradictions. Such variations should all be considered to fall within the protection scope of this invention.

[0021] The invention is described more specifically by way of example in the following paragraphs with reference to the accompanying drawings. The advantages and features of the invention will become clearer from the following description. It should be noted that the drawings are in a very simplified form and use non-precise proportions, and are only used to facilitate and clarify the illustration of the embodiments of the invention.

[0022] Example 1 like Figure 1 As shown, this embodiment proposes a test breakpoint control method for the ATE diagnostic process, which solves the problems of existing ATE diagnostic breakpoint control relying on software code, having a high operational threshold, being unable to accurately associate hardware identifiers, and having low fault location efficiency. The method includes the following steps: S1: Configure breakpoint parameters, which include the identification information of the target hardware unit and the triggering conditions.

[0023] S2: Load the breakpoint parameters into the test flow of the ATE diagnostic process.

[0024] S3: During the execution of the test process, the context information of the hardware unit currently being tested is obtained in real time, and the context information includes the identifier of the current hardware unit.

[0025] S4: Match the identifier of the current hardware unit with the identifier information of the target hardware unit. If the match is consistent and the triggering condition is met, trigger an interrupt to pause the current test process.

[0026] S5: In response to the recovery command, the interruption is lifted and the test process continues.

[0027] This embodiment uses a mobile phone motherboard as an example of the ATE diagnostic process for the device under test, and specifically explains the above steps S1-S5. Assume that the mobile phone motherboard under test needs to complete functional tests of hardware units such as the RF signal channel and power management module through ATE. The RF signal channel includes three independent channels: Channel1, Channel2, and Channel3. Each channel needs to be tested for signal transmission stability, power output accuracy, and other test items.

[0028] Step S1 aims to pre-set key parameters to identify the hardware objects and interrupt triggering rules that need to be monitored during the test, thus providing a basis for subsequent precise breakpoint control. Specifically, the configured breakpoint parameters include the identification information of the target hardware unit and the triggering conditions, which serve as the monitoring target and triggering rules for breakpoint control, respectively.

[0029] The identification information of the target hardware unit includes at least one of the following during ATE diagnostics: the board identifier, channel identifier, and test item name of the device under test. This identification information is crucial for distinguishing different hardware units and accurately locating the specific test object. In the ATE diagnostic scenario of the mobile phone motherboard in this embodiment, if maintenance personnel need to focus on monitoring the testing process of a specific hardware unit, they can select or input the corresponding identification information through the ATE system's configuration interface. For example, if the target is "the 'signal transmission stability' test item (i.e., test item name) of RF Channel2 (i.e., channel identifier) ​​on the mobile phone motherboard (i.e., board identifier) ​​of model M-2025," then the identification information of the target hardware unit is configured as {board identifier: M-2025, channel identifier: Channel2, test item name: signal transmission stability test}. If only all test items of a single board need to be monitored, only the board identifier is configured (e.g., {board identifier: M-2025}), thus demonstrating the flexibility and specificity of the identification information.

[0030] Furthermore, the triggering conditions include at least one of the following: triggering when the test process enters the testing phase of the target hardware unit, triggering when the test result of the target hardware unit fails, and triggering when the global test is enabled. These conditions define when to trigger the interrupt and can be flexibly combined according to actual debugging needs. As an example, in the above mobile phone motherboard testing scenario, maintenance personnel configure dual triggering conditions: first, when the test process enters the signal transmission stability test phase of Channel 2, an interrupt is triggered to facilitate checking the initial state of the hardware at the start of the test; second, if the result of the test item fails, such as the signal packet loss rate exceeding a preset threshold of 5%, an interrupt is triggered again to facilitate capturing the real-time state of the fault; at the same time, the global test enable state is set to on, so that the above breakpoint configuration takes effect throughout the entire test process.

[0031] Once configured, the breakpoint parameters will be stored in JSON format, which is convenient for maintenance personnel to view and modify intuitively, and also facilitates the ATE system to quickly parse and load them in subsequent steps, providing support for real-time monitoring and breakpoint triggering in the testing process.

[0032] Step S2 aims to transform the breakpoint parameters configured in step S1 from static configuration into dynamic instructions that can be invoked by the test system in real time. Specifically, the loading operation occurs before the ATE system starts the test process. At this time, the ATE system actively reads the breakpoint parameters generated in step S1 and transmits these breakpoint parameters to the control module of the test process, which is usually an embedded diagnostic program, through an internal data interface. This control module is responsible for scheduling the test sequence, collecting hardware data, and executing control logic. The loading of breakpoint parameters here ensures that the testing phase of each hardware unit can be monitored in real time during the test process.

[0033] It should be noted that, to avoid invalid configurations interfering with testing, the system will simultaneously verify the validity of parameters during the loading process. The verification mainly includes the following two aspects: First, it verifies whether the identification information of the target hardware unit matches the current device under test. For example, if the device under test is a motherboard with the board identifier M-2025, it needs to be confirmed whether M-2025 actually exists in the device model list to avoid breakpoints failing to trigger due to incorrect identification. Second, it checks whether there are logical conflicts in the triggering conditions. For example, if both triggering only on test failure and triggering only on test start are configured simultaneously, the system will determine this as a condition conflict and prompt for correction. If the verification passes, the system will automatically activate the breakpoint function, putting the breakpoint parameters into a standby state; if the verification fails, the system will clearly indicate the error type through the interactive interface, such as the channel identifier Channel2 not existing in the current device, requiring maintenance personnel to correct the configuration and reload.

[0034] Taking the testing of the mobile phone motherboard M-2025 as an example, after the Channel2 channel, signal transmission stability test items, and breakpoint parameters corresponding to the trigger conditions of the target hardware unit M-2025 motherboard are loaded, the real-time control unit of ATE will associate these parameters with the hardware call sequence in the test process. That is, when the system executes the test, it will automatically compare the loaded breakpoint parameters with each hardware unit test phase, thereby providing accurate judgment basis for context information matching in step S3 and interrupt triggering in step S4.

[0035] The purpose of step S3 is to continuously and dynamically obtain the context information of the hardware unit currently being tested during the execution of the ATE diagnostic test process, so as to provide an accurate basis for subsequent identifier matching and interrupt triggering.

[0036] Specifically, the ATE system proceeds step by step according to a preset test sequence, such as sequentially testing different channels and test items on the mobile phone motherboard. Throughout this process, the system's built-in embedded tracking module runs continuously. This module captures the hardware unit details corresponding to the current test stage in real time and generates context information containing key information. It should be noted that this context information must at least include the identifier of the current hardware unit configured in step S1 to ensure accurate matching later.

[0037] As an example, when the test process enters the "Signal transmission stability test of Channel 1 on the M-2025 motherboard" stage, the embedded tracking module immediately collects and generates context information: {Current board identifier: M-2025, Current channel identifier: Channel 1, Current test item name: Signal transmission stability test}. When the test process progresses to the "Signal transmission stability test of Channel 2 on the M-2025 motherboard," the context information is updated in real time to: {Current board identifier: M-2025, Current channel identifier: Channel 2, Current test item name: Signal transmission stability test}. Through this real-time acquisition and updating of context information, the ATE system can always clearly understand which hardware unit is currently being tested, thus providing accurate and timely data support for determining whether the current identifier matches the target identifier in step S4.

[0038] Furthermore, in step S4, when the ATE system executes the test process, it will use the matching module to compare the identifiers contained in the context information of the current hardware unit obtained in real time in step S3, such as the identifier of the board being tested, the channel identifier, the test item name, etc., with the identifier information of the target hardware unit configured in step S1, so that the two correspond to each other.

[0039] Based on the above-mentioned matching of identifiers, the system will further verify whether the triggering conditions set in step S1 are met. Only when the identifier of the current hardware unit is completely consistent with the target identifier and the triggering conditions are met will the system immediately trigger an interrupt, suspend the currently executing test process, and lock the test scenario at the time of the interruption.

[0040] Furthermore, when an interrupt is triggered, the system automatically saves the hardware status data of the device under test and the test process execution data at the time of the interruption. The hardware status data includes the physical parameters of the target hardware unit, such as the real-time signal strength, power supply voltage, and operating temperature of the mobile phone motherboard's Channel 2 channel. The test process execution data includes the current test progress, the sequence of executed instructions, and generated error codes. This data provides direct evidence for subsequent maintenance personnel to analyze problems, making the interruption scene traceable and the problem accurately located.

[0041] For step S5, after the interruption in step S4 is triggered (such as an interruption triggered by the failure of the Channel2 test), the system will not directly terminate the entire test process, but will enter an interrupt waiting state.

[0042] Before responding to the recovery command, the system first displays the identification information of the target hardware unit (such as the Channel2 channel of the M-2025 motherboard, with the test item being signal transmission stability test) and the interruption reason (such as the interruption being triggered due to test failure, with a packet loss rate of 20% exceeding the 5% threshold) to the maintenance personnel through the ATE's interactive interface (such as a touch screen or operation panel). This display allows maintenance personnel to intuitively understand the specific hardware object and triggering reason for the interruption without relying on code or professional tools. At the same time, the interface supports maintenance personnel to input operation commands, such as clicking the "View Data" button to retrieve the hardware status data and test process running data saved at the time of the interruption in step S4, or directly initiating inspection prompts for the Channel2 physical interface and adjusting test parameter thresholds through interface operations, thereby achieving targeted handling of the interruption scenario.

[0043] After maintenance personnel complete troubleshooting or parameter adjustments, they can input a recovery command through the interface (such as clicking the "Continue Testing" button). The system will then respond to this command by immediately resolving the current interruption, recalling the test context information saved before the interruption (such as completed test steps and the current hardware unit's test progress), and continuing the subsequent test process from the paused point. For example, if the interruption occurs during the signal transmission stability test of Channel 2, the remaining steps of that test item will continue after recovery. If the test item has been completed but was interrupted due to failure, the system will proceed according to the preset process to the next test item of Channel 2 (such as power output accuracy test) or switch to another channel (such as Channel 3) for testing. This ensures that the entire ATE diagnostic process is unaffected by interruptions, balancing the accuracy of problem handling with the continuity of the test process.

[0044] Example 2 This embodiment provides a test breakpoint control system for the ATE diagnostic process, which solves the problems of low efficiency in traditional ATE diagnostics due to reliance on code breakpoints and hardware problem localization, and achieves precise breakpoint control of hardware units during testing. Taking a mobile phone motherboard ATE diagnostic scenario as an example, the system includes a configuration module, a loading module, a tracing module, a matching and interruption module, and an interaction and recovery module.

[0045] In the specific implementation of this system, the diagnostic program can be written in Python or C / C++, and the modules work together through code-level design.

[0046] The configuration module receives breakpoint parameters set by maintenance personnel. To lower the operational barrier, this module supports parameter configuration via a visual interface (such as the touchscreen menu of an ATE device). Maintenance personnel do not need to write code; they only need to select the identification information of the target hardware unit through a drop-down menu or input box. This identification information includes at least one of the following: the board identifier of the device under test (e.g., mobile phone motherboard model M-2025), the hardware channel identifier (e.g., RF channel Channel2), and the test item name (e.g., signal transmission stability test). Simultaneously, trigger conditions are set. For example, an interrupt is triggered when the test process enters the signal transmission stability test stage of Channel2; another interrupt is triggered when the test item fails, and the breakpoint function is enabled in the global test enable state. After configuration, the parameters are temporarily stored in a structured format for subsequent module calls. The specific breakpoint parameters of the configuration module are stored in a JSON format configuration file `breakpoint_config.json`. For example, for the Channel2 test of the mobile phone motherboard M-2025, the configuration file can be set as follows: {"BreakpointTypes":["BPStart","BPFailed","BPSucceed"], / / Corresponds to the test phase entry, failure, and success states in the trigger conditions. "DebugEnable":true, / / Enables global testing "DebuggerUrl":"tcp: / / localhost:7555", / / Communication address of the interactive module "TestItem":"Signal Transmission Stability Test" / / Target test item identifier} This configuration file clearly defines the associated test items, trigger types, and global enable states of the target hardware unit, which can be read and verified by the loading module.

[0047] The loading module is used to load the breakpoint parameters set in the configuration module into the ATE diagnostic test process. Before the test starts, the loading module reads the parameters temporarily stored in the configuration module and verifies their validity (such as whether Channel2 is a valid channel for the M-2025 motherboard). If the verification is successful, the parameters are loaded into the ATE's real-time test control program, enabling the system to identify the target hardware unit and trigger rules in real time during the test. For example, when the test sequence for the M-2025 motherboard starts, the loading module successfully loads the breakpoint parameters for the Channel2 signal transmission stability test, allowing the system to accurately monitor this hardware unit in subsequent tests.

[0048] The tracking module is used to acquire the context information of the currently tested hardware unit in real time during the test process. This context information includes the identifier of the current hardware unit (such as the board, channel, and test item name). For example, when the ATE executes the Channel1 power test, Channel2 signal transmission stability test, and Channel3 anti-interference test sequentially, the tracking module dynamically updates the context information: when testing Channel1, the context is M-2025 motherboard, Channel1, and power test; when entering the Channel2 signal transmission stability test, the context is updated to M-2025 motherboard, Channel2, and signal transmission stability test, and is simultaneously sent to the matching and interrupt module.

[0049] Specifically, the tracing module is implemented using the shared library breakpoint_mgr.so, which includes the core function brkp_send_request, used to collect context information of the current hardware unit in real time (such as board identifier, channel identifier, test items, etc.). In the diagnostic code, key nodes of each test item call the macro BRKP_REQUEST, which encapsulates this function. For example, in the signal transmission stability test function run_test_item_a of Channel2 on the mobile phone motherboard: void run_test_item_a(size_t chn) / / chn is the channel identifier, here corresponding to the channel number of Channel2 { / / Test preparation code BRKP_REQUEST("Signal Transmission Stability Test",chn,"",BPStart); / / Triggered at the start of the test, passing the test item and channel identifier. / / Test execution code (such as signal sending and receiving detection) if(result==false){ / / When the test fails BRKP_REQUEST("Signal transmission stability test",chn,"",BPFailed); / / Transmission failure status } / / Test end code BRKP_REQUEST("Signal transmission stability test",chn,"",BPEnd); / / Triggered when the test ends} In the macro function, bkmgr_chk_debug checks whether the current context matches the configured target hardware unit identifier and triggering conditions. If it matches, it sends the information to the matching and interrupt module via brkp_send_request.

[0050] The matching and interruption module compares the current hardware unit identifier obtained by the tracking module with the target hardware unit identifier information set by the configuration module. If they match and the triggering conditions are met, an interrupt is immediately triggered to pause the current test process. Furthermore, this module includes a state saving unit, which automatically saves the hardware state data and test process execution data at the time of the interruption. For example, when the tracking module detects that the current test is the signal transmission stability test phase of Channel 2, and the identifier matches and the triggering conditions for entering the test phase are met, the module triggers the first interrupt; if the result of this test item is a failure, the triggering conditions are met again, triggering a second interrupt.

[0051] Specifically, after receiving information from the tracing module, if the interruption condition is met, the matching and interruption module will call the interrupt handling function enter_debug_wait_loop() to pause the test process. This function achieves this by looping through shared memory or Socket commands. void enter_debug_wait_loop() { while (true) { if (receive_user_command() == CMD_CONTINUE) { / / Receive "Continue" command break; / / Release interrupt }else if(receive_user_command()==CMD_ABORT){ / / Receive "abort" command exit_diagnostics(); / / Terminate the test } sleep_ms(100); / / Wait for instructions }} Meanwhile, the module's state saving unit will automatically store the current hardware state data (such as the signal strength and packet loss rate of Channel2) and running data (such as the execution progress and error code of run_test_item_a) when an interrupt occurs, for subsequent analysis.

[0052] The interaction and recovery module is used to respond to recovery commands, clear the interruption, and control the continuation of the test process. Specifically, it includes a display unit and a command receiving unit. The display unit, after an interruption occurs, displays interruption-related information to maintenance personnel through an interface. For example, the target hardware unit is the M-2025 motherboard Channel 2; the test item is signal transmission stability test; the interruption reason is test failure (packet loss rate 20% > threshold 5%). It also provides a query entry for saved hardware status data and operating data. The command receiving unit receives operation commands from maintenance personnel, such as pausing the check or continuing the test. Once the maintenance personnel confirm the problem has been resolved and input a command to continue testing, the module responds to the command, clears the interruption, recalls the test context information saved before the interruption, and continues execution of the subsequent process from the paused point (such as completing the remaining test items in Channel 2 or proceeding to Channel 3).

[0053] Specifically, the interaction and recovery module is implemented through a TCP Socket server (corresponding to DebuggerUrl in the configuration file) or a web interface, namely the display unit and the command receiving unit. When the Channel2 test triggers an interrupt, the interface will display a prompt: "Target hardware unit: M-2025 motherboard Channel2, test item 'signal transmission stability test'; interrupt type: BPFailed", and show the saved status data. Maintenance personnel can send CMD_CONTINUE (continue) or CMD_ABORT (abort) commands through the interface. The commands are transmitted to the interrupt handling module via the Socket to complete the recovery or termination of the test process.

[0054] In summary, this system lowers the operational threshold through visual configuration, achieves precise matching based on hardware identifiers, supports multiple trigger conditions, automatically saves critical data during interruptions, and enables flexible recovery through human-computer interaction. Compared to traditional debugging methods that rely on code breakpoints, this system can quickly locate hardware problems, reduce the impact of test interruptions on production, and significantly improve the efficiency and flexibility of ATE diagnostics. It is suitable for automated testing scenarios of various complex hardware such as mobile phone motherboards and automotive electronic modules.

[0055] Through the above specific implementation, the various modules of the system form a complete closed loop from parameter configuration and real-time tracking to interrupt control and interactive recovery. Through code-level design, precise breakpoint control based on hardware units is achieved, thereby greatly improving the operability and efficiency of ATE diagnostics.

[0056] The above are merely preferred embodiments of the present invention and do not constitute any limitation on the present invention. Any equivalent substitutions or modifications made by those skilled in the art to the technical solutions and content disclosed in the present invention without departing from the scope of the present invention shall be deemed to have remained within the protection scope of the present invention.

Claims

1. A test breakpoint control method for ATE diagnostic process, characterized in that, Includes the following steps: Configure breakpoint parameters, which include the identification information of the target hardware unit and the triggering conditions; The breakpoint parameters are loaded into the test flow of the ATE diagnostic process; During the execution of the test process, the context information of the hardware unit currently being tested is obtained in real time, and the context information includes the identifier of the current hardware unit; The identifier of the current hardware unit is matched with the identifier information of the target hardware unit. If the match is consistent and the triggering condition is met, an interrupt is triggered to pause the current test process. In response to the recovery command, the interruption is lifted and the test process continues.

2. The method according to claim 1, characterized in that, The identification information of the target hardware unit includes at least one of the following during ATE diagnostics: the board identifier, channel identifier, and test item name of the device under test.

3. The method according to claim 1, characterized in that, The triggering conditions include at least one of the following: when the test process enters the test phase of the target hardware unit, when the test result of the target hardware unit is a failure, and when the global test is enabled.

4. The method according to claim 1, characterized in that, The step of triggering the interrupt further includes: saving the hardware status data of the device under test and the running data of the test process at the time of the interruption, wherein the hardware status data includes the physical parameters of the target hardware unit.

5. The method according to claim 1, characterized in that, Before responding to the recovery command, the method further includes: displaying the identification information of the target hardware unit and the reason for the interruption through an interactive interface, and receiving input operation commands.

6. A test breakpoint control system for ATE diagnostic processes, characterized in that, It includes a configuration module, a loading module, a tracing module, a matching and interruption module, and an interaction and recovery module: The configuration module is used to receive input breakpoint parameters, which include the identification information of the target hardware unit and the triggering conditions. The loading module is used to load the breakpoint parameters into the test flow during the ATE diagnostic process; The tracking module is used to obtain the context information of the hardware unit currently being tested in real time during the execution of the test process. The context information includes the identifier of the current hardware unit. The matching and interruption module is used to match the identifier of the current hardware unit with the identifier information of the target hardware unit. If the match is consistent and the triggering condition is met, an interruption is triggered to pause the current test process. The interaction and recovery module is used to respond to the recovery command, release the interruption, and control the test process to continue execution.

7. The system according to claim 6, characterized in that, The configuration module supports inputting the identification information of the target hardware unit through a visual interface. The identification information includes at least one of the following during ATE diagnostics: the board identifier of the device under test, the hardware channel identifier, and the test item name.

8. The system according to claim 6, characterized in that, The matching and interruption module also includes a status saving unit, which is used to save the hardware status data of the device under test and the running data of the test process at the time of the interruption when an interruption is triggered.

9. The system according to claim 6, characterized in that, The interaction and recovery module includes a display unit and an instruction receiving unit; the display unit is used to display the identification information of the target hardware unit and the reason for the interruption; the instruction receiving unit is used to receive input recovery instructions or debugging instructions.

10. The system according to claim 6, characterized in that, The triggering conditions include at least one of the following: triggering when the test process enters the test phase of the target hardware unit, triggering when the test result of the target hardware unit is a failure, and triggering when the global test is enabled.

Images