Tunneling algorithm control chip test method, device, system, equipment and storage medium

Abstract

This application relates to a method, apparatus, system, computer device, and computer-readable storage medium for testing inductive computing chips. The method includes: testing the chip under test based on an executable test load image; during the testing of the chip under test, determining the next execution node based on the actual response generated by the chip under test executing the current test task, wherein the next execution node includes the next test task or test termination; and determining the chip test result based on the test execution record of the chip under test. This method can determine the corresponding next test task based on the actual response of the chip under test, thereby improving the reliability of chip testing.

Description

Technical Field

[0001] This application relates to the field of automatic testing technology, and in particular to a testing method, apparatus, system, computer equipment, and computer-readable storage medium for a sensing and control chip. Background Technology

[0002] With the rapid development of automated testing technology, most chips are now tested automatically using automated testing equipment and programs. For example, packaged sensing and control chips can now be batch tested under conditions close to actual application environments.

[0003] Currently, the complete test task is first determined based on the chip's function, communication protocol, and specific application scenario. The input data, timing, power supply, specific task sequence, and communication environment of the complete test task are configured as a standard test load, and a test load image that can be called repeatedly is generated. Then, the testing equipment loads the test load image onto each chip under test in sequence, collects its communication response, and compares it with the expected results and judgment range. Based on this, the chip test results such as qualified, unqualified, or pending retest are output.

[0004] However, existing technology first generates multiple standard test loads, and then forms test load mirrors in a predetermined order. When the chip under test executes one of the test tasks and encounters different responses, it continues to execute the fixed baseline path indicated by the test load mirror. As a result, the real abnormal test path of the chip under test in the actual scenario is not reproduced, which leads to a decrease in the reliability of chip testing. Summary of the Invention

[0005] Therefore, it is necessary to provide a testing method, apparatus, system, computer equipment, and computer-readable storage medium for inductive computing and control chips that can determine the next test task based on the actual response of the chip under test, in order to address the above-mentioned technical problems.

[0006] Firstly, this application provides a method for testing a sensor-controlled computing chip, the method comprising:

[0007] Based on the executable test load image, the chip under test is tested; during the test of the chip under test, the next execution node is determined based on the actual response generated by the chip under test executing the current test task, and the next execution node includes the next test task or test termination;

[0008] Based on the test execution records of the chip under test, the chip test results of the chip under test are determined.

[0009] In one embodiment, determining the next execution node based on the actual response generated by the chip under test executing the current test task includes:

[0010] Determine each response binding image record associated with the current test task; each of the response binding image records is used to record the response transfer conditions and the next execution node identification information bound to the current test task, the response transfer conditions are used to indicate the conditions for executing the next execution node, and the next execution node identification information includes the next test task identification information or the identification information indicating test termination;

[0011] Based on the actual response generated by the current test task executed by the chip under test, and the image records bound to each response, the next execution node is determined.

[0012] In one embodiment, any of the response binding mirror records is further used to record complete response determination conditions bound to the current test task, wherein the complete response determination conditions are used to determine whether the actual response forms a complete response;

[0013] The process of determining the next execution node based on the actual response generated by executing the current test task on the chip under test, and the image records bound to each response, includes:

[0014] Within the target specified time period, if the actual response meets the complete response judgment condition bound to the current test task, the actual response result of the current test task is determined based on the actual response, and at least one target response transfer condition with a complete and parseable response as the judgment content is determined from the response transfer conditions indicated by each response-bound mirror record.

[0015] If the actual response does not meet the complete response judgment condition bound to the current test task within the target specified time period, the actual response result of the current test task is determined based on the actual timeout result of the task having timed out, and at least one target response transfer condition with timeout result as the judgment content is determined from the response transfer conditions indicated by each response-bound mirror record.

[0016] Based on the comparison results of the actual response results with each of the target response transfer conditions, and the identification information of each of the next execution nodes, the next execution node is determined;

[0017] The target specified time period is a time period that starts at the time when the data sent by the current test task is completed and is timed by a preset response timeout duration.

[0018] In one embodiment, any of the response binding mirror records is further used to record dynamic field references bound to the current test task;

[0019] After determining the next execution node based on the actual response generated by executing the current test task on the chip under test, and the image records bound to each response, the method further includes:

[0020] When the next execution node is the next test task, the dynamic field is obtained based on the dynamic field reference indicated by the response binding image record that is jointly associated with the current test task and the next test task; the dynamic field is a field that changes dynamically during the test.

[0021] Based on the dynamic field, the sending data for the next test task is generated.

[0022] In one embodiment, the actual response is generated based on response data belonging to the current test task;

[0023] During the testing process of the chip under test, the method further includes:

[0024] Upon obtaining new response data, the new response data is compared with the attribution criteria of the response data of each incomplete task in the incomplete task set.

[0025] If the new response data is successfully matched with the response data of only one incomplete task in the set of incomplete tasks, the new response data will be assigned to the incomplete task that was successfully matched.

[0026] If the new response data is successfully matched with the response data attribution criteria of at least two incomplete tasks in the set of incomplete tasks, the new response data is determined to be response attribution conflict data.

[0027] If the new response data fails to match the attribution criteria of the response data of all incomplete tasks in the incomplete task set, the new response data is determined to be unattributable data.

[0028] Wherein, any of the unfinished tasks are tasks that have sent data but have not formed a complete response, and the current time has not exceeded the specified time period of the unfinished task; the specified time period of the unfinished task is a time period with the completion time of sending the sent data of the unfinished task as the start time and a preset response timeout duration as the time interval; the response data attribution condition of any of the unfinished tasks is used to indicate the conditions under which new response data belongs to the unfinished task.

[0029] In one embodiment, the executable test load image is generated based on the following method:

[0030] Based on the field communication logs of the benchmark chip executing a preset business process, multiple mirror task units are generated; the preset business process includes multiple test tasks executed sequentially, and the field communication logs are communication logs with the benchmark chip.

[0031] Based on the execution data of the preset business process executed by the benchmark chip, a binding image record between each of the test tasks is generated; any one of the binding image records is used to record the binding relationship between two test tasks.

[0032] Based on the multiple image task units and each of the bound image records, an initial test load image is generated;

[0033] If the initial test load image passes the inspection, the encapsulation test conditions are written into the initial test load image to generate the executable test load image.

[0034] Secondly, this application also provides a testing device for a sensing and control chip, the device comprising:

[0035] The chip testing module is used to test the chip under test based on an executable test load image; during the testing process of the chip under test, the next execution node is determined based on the actual response generated by the chip under test executing the current test task, wherein the next execution node includes the next test task or test termination;

[0036] The result determination module is used to determine the chip test result of the chip under test based on the test execution record of the chip under test.

[0037] Thirdly, this application also provides a testing system for a sensing and control chip, the system comprising:

[0038] A test load board, which is used to connect to the chip under test;

[0039] A computer device, the computer device being configured to perform the steps of the method as described in any of the preceding methods;

[0040] The test machine is communicatively connected to both the test load board and the computer device.

[0041] Fourthly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0042] Based on the executable test load image, the chip under test is tested; during the test of the chip under test, the next execution node is determined based on the actual response generated by the chip under test executing the current test task, and the next execution node includes the next test task or test termination;

[0043] Based on the test execution records of the chip under test, the chip test results of the chip under test are determined.

[0044] Fifthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0045] Based on the executable test load image, the chip under test is tested; during the test of the chip under test, the next execution node is determined based on the actual response generated by the chip under test executing the current test task, and the next execution node includes the next test task or test termination;

[0046] Based on the test execution records of the chip under test, the chip test results of the chip under test are determined.

[0047] The aforementioned testing method, apparatus, system, computer equipment, and computer-readable storage medium for inductive computing and control chips test the chip under test based on an executable test load image. During the testing process of the chip under test, the next execution node is determined based on the actual response generated by the chip under test when executing the current test task. This allows the next test task to be determined according to the actual response of the chip under test, ensuring that the actual test path of the chip under test is consistent with the actual response and current operating state of the chip under test. In other words, it can continuously reproduce real abnormal test paths such as retries, link switching, or recovery. Compared with the fixed baseline path in the prior art, this embodiment can improve the reliability of chip testing. Attached Figure Description

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

[0049] Figure 1 This is one of the flowcharts illustrating the testing method for the sensing and control chip provided by the present invention;

[0050] Figure 2 This is the second flowchart illustrating the testing method for the sensing and control chip provided by this invention;

[0051] Figure 3 This is the third flowchart of the testing method for the sensing and control chip provided by the present invention;

[0052] Figure 4 This is the fourth flowchart of the testing method for the sensing and control chip provided by the present invention;

[0053] Figure 5 This is the fifth flowchart illustrating the testing method for the sensing and control chip provided by this invention;

[0054] Figure 6 This is a schematic diagram of the structure of the inductive computing and control chip testing device provided by the present invention;

[0055] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0057] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0058] In one embodiment, such as Figure 1 As shown, a testing method for a sensing and control chip is provided. This embodiment illustrates the application of this method to a terminal. It is understood that this method can also be applied to a server, and to a system including both a terminal and a server, and is implemented through the interaction between the terminal and the server. In this embodiment, the method includes the following steps: step 101 and step 102.

[0059] Step 101: Test the chip under test based on the executable test load image; during the test of the chip under test, determine the next execution node based on the actual response generated by the chip under test executing the current test task, the next execution node includes the next test task or test termination.

[0060] Here, the chip to be tested can be either the chip to be tested or the chip to be screened. In a specific embodiment, the chip to be tested refers to a single chip that needs to be functionally verified, communication verified, and qualified after packaging by an executable test load image, including but not limited to a sensing and control chip.

[0061] Here, the executable test load image can be used to execute one or more test tasks sequentially. In a specific embodiment, it refers to structured test data consisting of image task units and response-bound image records, which can be loaded and executed in a closed loop by the test equipment. It should be understood that the executable test load image not only contains test data, but also includes jump logic that can select the subsequent path based on the actual response of the chip under test.

[0062] Here, a test task refers to a pre-set business test unit in the test process, such as power-on startup, firmware flashing, networking, business communication, link switching, or recovery tasks. The current test task is a task that is not yet completed during the execution of an executable test load image.

[0063] Here, the actual response refers to the actual response generated by the chip under test (TBT) during the execution of the current test task. In one specific embodiment, the actual response is generated based on the response data belonging to the current test task. For example, the actual response refers to the real-time communication feedback generated by the TBT during the execution of the current test task, which may include, but is not limited to, at least one of the following: response data (such as message content), response status, key flag bits, and actual response latency returned by the TBT.

[0064] Here, the next execution node refers to the next node to be executed after the current test task is completed. This could be the execution of the next test task or the termination of the test. For example, the test may terminate after all test tasks have been completed. In other words, the next execution node refers to the logical target after the current test task ends, including but not limited to the identifier information of the next test task to be executed, or a termination state representing test completion, chip failure, or test invalidity.

[0065] In some embodiments, when executing the current test task, each response binding image record associated with the current test task is determined; based on the actual response generated by the chip under test executing the current test task, and each response binding image record, the next execution node is determined. Each response binding image record is used to record the response transition conditions bound to the current test task, and the response transition conditions are used to indicate the conditions for executing the next execution node. Specific details can be found in the following embodiments, which will not be elaborated upon here.

[0066] In one embodiment, any response-bound mirror record is further used to record the complete response determination condition bound to the current test task. The complete response determination condition is used to determine whether the actual response forms a complete response. If the actual response meets the complete response determination condition bound to the current test task within the target specified time period, the actual response result of the current test task is determined based on the actual response, and at least one target response transfer condition with a complete and parseable response as the judgment content is determined from the response transfer conditions indicated by each response-bound mirror record. If the actual response does not meet the complete response determination condition bound to the current test task within the target specified time period, the actual response result of the current test task is determined based on the actual timeout result of the task having timed out, and at least one target response transfer condition with a timeout result as the judgment content is determined from the response transfer conditions indicated by each response-bound mirror record. Based on the comparison results of the actual response result with each target response transfer condition, the next execution node is determined. The target specified time period is a time period starting from the completion time of sending the data already sent by the current test task and with a preset response timeout duration as the time interval.

[0067] In one embodiment, if only one of the target response transfer conditions successfully matches the actual response result, the next execution node is determined; if all target response transfer conditions fail to match the actual response result, response processing is determined to be missing and the test is terminated; if at least two of the target response transfer conditions successfully match the actual response result, response transfer condition conflict is determined and the test is terminated.

[0068] In one embodiment, the actual response result of the current test task is determined based on the actual response generated by the chip under test executing the current test task, and the next execution node is determined based on the actual response result and the image records bound to each response.

[0069] In one specific embodiment, a specified version of the executable test load image is loaded onto the chip to be tested in order to execute the executable test load image.

[0070] In one embodiment, an abnormal response is recorded only when an undefined response condition is met.

[0071] In one embodiment, if the current test task fails to generate a complete response that matches the explicit response transition conditions after reaching the retry limit for the number of consecutive retries, the retry is recorded as a failure.

[0072] For example, the package batch and chip serial number of the chip under test are written into the test execution record, the chip under test is installed into the adapter, the test load board connection, actual voltage, environment and communication interface are checked, and the specified version of the executable test load image is loaded; starting from the power-on startup entry, for each test task executed, the number of the current test task, the number of the previous test task, the start time of the current test task and the completion time of the transmission of the data sent by the current test task are recorded.

[0073] It should be understood that by executing an executable test load image, the transformation from static instruction replay to dynamic logic simulation is realized, and a communication load environment that closely resembles the actual application scenario is constructed. This provides a basic platform for subsequently reproducing the chip's response behavior in real-world tasks, ensuring the initial consistency and repeatability of the testing process.

[0074] It should be understood that when executing the current test task, a fixed sequence is no longer blindly followed. Instead, the actual response generated by the chip under test is collected in real time. By matching this actual response with the response transition conditions associated with the current test task, the next execution node is dynamically determined. If the match is successful, the process jumps to the next test task or enters a preset termination state. If an abnormal response or timeout occurs, the process enters a retry or exception handling path according to the mirror logic. Based on this, the problem of misalignment between the test process and the state of the chip under test caused by the fixed replay reference path in the prior art is solved. Through the response-driven mechanism, the test equipment can automatically trigger the continuous reproduction of real abnormal paths such as retries, link switching, or recovery based on the actual state of the chip under test. This significantly improves the ability to detect chip performance boundaries and reliability defects, reduces misjudgments of chip quality, and thus improves the reliability of chip testing.

[0075] Step 102: Based on the test execution record of the chip under test, determine the chip test result of the chip under test.

[0076] Here, the test execution record refers to the data recorded during the execution of the executable test load image by the chip under test. Specifically, the test execution record refers to the structured log automatically generated during the execution of the executable test load image. This test execution record may include, but is not limited to, at least one of the following: the package batch of the chip under test, the chip serial number of the chip under test, the current test task identifier, the identifier of the previous test task, the completion time of the data sent by the current test task, the entry conditions for each test task, the start time of each test task, the end time of each test task, the identifier of the next test task or the identifier indicating test termination, the actual task path formed by connecting time, the complete response of each test task, the record of dynamically generated fields, the record of invalid test termination, abnormal responses, performance test failures, abnormal resets, the execution result of the first failed task, the task timeout record, the actual response latency of the task, the current number of consecutive retries, the source task number referenced by the dynamic fields, the position of the source response data field, the image version used in this test, etc.

[0077] Here, chip test results can include qualified chips, unqualified chips, or invalid tests.

[0078] In one embodiment, when the current task is a communication rate test task, the effective service data volume and corresponding transmission duration confirmed by the receiving end are counted according to the chip communication protocol or test specification of the chip under test, and compared with the lower limit of communication rate stored in the executable test load image. Based on the comparison result, the chip test result of the chip under test is determined.

[0079] In one embodiment, if the test execution record of the chip under test includes a test invalidation termination record, the chip test result of the chip under test is neither qualified nor unqualified. After the executable test load image is corrected or the test conditions are restored, the chip under test is retested, that is, the executable test load image is re-executed. For the chip under test that has passed the test, the execution results of each test task are read according to the task execution order in the actual task path. For example, if the power-on startup task or firmware burning subtask is not completed, a startup failure or burning failure is recorded at the corresponding test task position, and the actual task path enters the chip failure termination. After the power-on startup is completed, the execution results of the networking task are read again; if the networking is not completed, or the obtained response data cannot be parsed according to the chip communication protocol, a failure result is recorded at the networking task or the corresponding communication task position.

[0080] In one embodiment, the actual response latency of each test task is compared with the corresponding preset upper limit of response latency, and the communication rate test result is compared with the preset lower limit of communication rate; when the actual response latency exceeds the corresponding upper limit or the communication rate is lower than the lower limit of communication rate, the performance test is recorded as failed at the corresponding test task location.

[0081] In one embodiment, if during the execution of the executable test load image, it is detected that the chip under test has re-entered the power-on state, the reset flag has changed, or the startup message has reappeared, an abnormal reset is recorded, and the actual task path terminates due to chip failure. The first failed task is located according to the chronological order of the actual task path, and the valid chip test result for this chip under test is determined to be unqualified. If the actual task path sequentially completes the tasks specified in the executable test load image and reaches successful termination, and none of the test tasks result in failure, the valid chip test result for the current chip is determined to be qualified.

[0082] For example, test execution records are maintained throughout the entire testing process, recording the execution results, response codes, actual response latency, and number of retries for each test task in chronological order. After the test, the actual task path is analyzed, and by verifying the success or failure of the test task execution, whether the retry limit has been reached, and whether there are any undefined responses, the chip is ultimately determined to be qualified, unqualified, or require retesting.

[0083] For example, the test task that first encounters an unqualified condition in the actual task path and its record position are the first failure position. At the same time, the task execution result, complete response or timeout record, actual response latency, current consecutive retries, source task number and source response data field position referenced by the dynamic field, and the image version used in this test are saved.

[0084] Furthermore, the chip test results of the individual chip under test are correlated with the appearance, size, solder balls, voltage, current, power consumption, basic functions, and necessary reliability check results of the same chip.

[0085] It should be understood that this provides a closed-loop evidence for single-chip screening, enabling precise data support for subsequent packaging test yield analysis and failure localization by recording the first failure location and failure mode.

[0086] In the above-mentioned testing method for the sensing and control chip, the chip under test is tested based on the executable test load image. During the testing process of the chip under test, the next execution node is determined based on the actual response generated by the chip under test in executing the current test task. Thus, the next test task can be determined according to the actual response of the chip under test, ensuring that the actual test path of the chip under test is consistent with the actual response and current operating state of the chip under test. This enables the continuous reproduction of real abnormal test paths such as retry, link switching or recovery. Compared with the fixed reference path in the prior art, this embodiment can improve the reliability of chip testing.

[0087] Based on any of the above embodiments, in this method, step 101, determining the next execution node based on the actual response generated by the chip under test executing the current test task, includes:

[0088] Determine the image records associated with each response of the current test task;

[0089] Based on the actual response generated by the current test task executed by the chip under test, and the image records bound to each response, the next execution node is determined.

[0090] Wherein, any of the response binding mirror records is used to record the response transfer conditions and the next execution node identification information bound to the current test task. The response transfer conditions are used to indicate the conditions for executing the next execution node, and the next execution node identification information includes the next test task identification information or identification information indicating test termination.

[0091] Here, the response binding mirror record is a record formed by binding the current test task, the complete response judgment condition, the response transfer condition, the dynamic field references and conversion rules of the data sent by the next test task, and the identification information of the next test task or the identification information indicating the termination of the test. In other words, the response binding mirror refers to a structured data record that logically associates the current test task, the response transfer condition, and the next execution node. In one embodiment, it is extracted and generated from the response processing branch of the original application and is used to guide the test equipment on how to perform logical switching after receiving the response from the chip under test.

[0092] It should be noted that a test task can be bound to multiple response transition conditions, meaning the current test task can correspond to multiple response transition conditions in the response binding image record. Each response binding image record explicitly records the corresponding response transition condition. When the actual response of the chip under test meets specific conditions (e.g., the response code matches successfully and the number of retries has not reached the limit), the next execution node identifier information saved in the record determines whether to proceed to the next specific test task or terminate the test directly.

[0093] Here, the response transfer condition refers to the specific judgment logic for jumping from the current test task to the next execution node. The response transfer condition uses actual parameters such as the response code returned by the chip under test, key flag bits, whether a timeout has occurred (timeout result), and the current number of consecutive retries as the judgment object. That is, the response transfer condition may include, but is not limited to, at least one of the following: conditions that limit the response code, conditions that limit the key flag bits, conditions that limit the timeout result, and conditions that limit the current number of consecutive retries, etc.

[0094] Here, the next test task identifier is used to uniquely identify the next test task. It can be set according to actual needs, for example, it is the next test task number. This embodiment does not make a specific limitation. The identifier indicating the termination of the test can be set according to actual needs, for example, it is the test termination.

[0095] In one specific embodiment, the actual response result of the current test task is determined based on the actual response generated by the chip under test executing the current test task, and the next execution node is determined based on the actual response result and the image records bound to each response.

[0096] For example, each response binding mirror record associated with the current test task is checked in turn; when a response transfer condition limits the response code, key flag, timeout result, or current number of consecutive retries, the corresponding actual response result of the current test task is compared with the response transfer condition, and unlimited judgment items are not included in the comparison.

[0097] For example, when executing the current test task, all response binding image records that match the current test task are first retrieved and identified. Since there are often multiple processing branches (such as success branch, retry branch, exception branch, etc.) for the same task in the original business logic, a current test task usually corresponds to multiple response binding image records, forming a complete set of logical decisions.

[0098] It should be understood that by determining the associated response binding image records, the test process is ensured to cover all possible feedback paths of the chip under test. This one-to-many association mechanism has the ability to simulate complex business logic and provides a complete search range for subsequent accurate matching.

[0099] In the aforementioned testing method for the sensor-controlled computing chip, the explicitly bound next execution node identifier information and response transfer conditions ensure accurate determination of the next execution node, thereby improving the reliability and accuracy of chip testing. Furthermore, the bound multiple response transfer conditions give the testing process a strong self-healing capability; even if the chip under test experiences unexpected delays or fluctuations, it can still enter the corresponding processing path based on the bound response transfer conditions, thus further enhancing the reliability and accuracy of chip testing.

[0100] Based on any of the above embodiments, in this method, any of the response binding mirror records is further used to record the complete response determination conditions bound to the current test task, wherein the complete response determination conditions are used to determine whether the actual response forms a complete response; the step of determining the next execution node based on the actual response generated by the chip under test executing the current test task, and each of the response binding mirror records, includes:

[0101] Within the target specified time period, if the actual response meets the complete response judgment condition bound to the current test task, the actual response result of the current test task is determined based on the actual response, and at least one target response transfer condition with a complete and parseable response as the judgment content is determined from the response transfer conditions indicated by each response-bound mirror record.

[0102] If the actual response does not meet the complete response judgment condition bound to the current test task within the target specified time period, the actual response result of the current test task is determined based on the actual timeout result of the task having timed out, and at least one target response transfer condition with timeout result as the judgment content is determined from the response transfer conditions indicated by each response-bound mirror record.

[0103] Based on the comparison results of the actual response results with the target response transfer conditions, and the identification information of the next execution node, the next execution node is determined.

[0104] Here, the complete response determination condition refers to the set of rules used to determine whether the response data (such as response message) received by the current test task constitutes a complete logical information.

[0105] In some embodiments, according to the chip communication protocol, the complete response determination conditions may include, but are not limited to, at least one of the following: length condition (the number of bytes meets the expectation), end condition (the end flag is received), fragmentation condition (fragment sequence numbers are consecutive and complete), quantity condition, and node condition, etc.

[0106] In one embodiment, the conditions included in the complete response determination conditions are determined by the chip communication protocol corresponding to the current message type, that is, the chip communication protocol corresponding to the current message type stipulates one or more conditions that must be met.

[0107] In one embodiment, the length condition is determined as follows: according to the counting range specified by the chip communication protocol for the length field, the bytes in the response data (such as the response message) that has been included in the current test task are counted byte by byte. The same fragment that is received repeatedly is counted only once. Response data that cannot be parsed according to the chip communication protocol or fails to be verified is not included. When the number of bytes obtained is equal to the expected number of bytes represented by the length field of the current response data, the length condition is met.

[0108] In one embodiment, the termination condition is determined as follows: the termination condition is met when the termination flag specified by the chip communication protocol is received.

[0109] In one embodiment, the fragmentation condition is determined as follows: the fragmentation condition is met when all chips from the first chip to the last chip, as specified in the chip communication protocol, have been received and there are no missing chips.

[0110] In one embodiment, the quantity condition is determined as follows: the quantity condition is met when the number of response data already included in the current test task reaches the number specified by the chip communication protocol.

[0111] In one embodiment, the node condition is determined as follows: the node condition is met when every node in the node set specified by the chip communication protocol has returned response data.

[0112] It should be noted that when a chip communication protocol specifies two or more complete response criteria for the same message type, only when all the specified conditions are met will the actual response already assigned to the current test task be considered a complete response. Conditions not specified in the chip communication protocol are not included in the judgment.

[0113] In other embodiments, when the chip communication protocol does not specify the total length, end flag, total number of fragments, specified number of responses, and specified node set for determining a complete response, a response reception idle timer is started after each response data already assigned to the current test task is received. If new response data belonging to the current test task is received during the timer period, the response reception idle timer is reset to zero, and the timer restarts from the moment the new response data is received. This timer is used to determine whether the current test task has stopped returning new response data. If the response reception idle timer continuously counts until the response reception idle time is reached, and no new response data belonging to the current test task is received during the timer period, the actual response previously assigned to the current test task is determined to be a complete response. The response reception idle time preferentially adopts the maximum response frame interval specified by the chip communication protocol; if the chip communication protocol does not specify it, the existing reception waiting time of the application is used. If neither the maximum response frame interval nor the reception waiting time exists, a complete response determination condition is marked as missing, and the generation of the executable record for the current test task is stopped.

[0114] The target specified time period is a time period that starts at the time when the data sent by the current test task is completed and is timed by a preset response timeout duration.

[0115] Here, the data sent refers to the data that needs to be sent to begin executing the current test task, such as a sent message.

[0116] In one specific embodiment, the preset response timeout duration is the longest waiting time extracted from the receive waiting time or timeout judgment value set by the application for the current test task when generating the test load image. Further, if the mandatory response time specified by the chip communication protocol is shorter than this longest waiting time, the mandatory response time specified by the chip communication protocol is used as the preset response timeout duration.

[0117] Here, the actual response result is the actual response result of the current test task, which is used to indicate the actual running status of the current test task.

[0118] Here, a complete and parseable response refers to an actual response received within the specified target time period that meets the criteria for a complete response. For example, an actual response includes response data that can be parsed according to the chip's communication protocol to obtain specific response codes and key flag bits.

[0119] Here, the actual timeout result means that the task has timed out. The actual timeout result refers to the fact that the chip under test has not generated feedback that meets the complete response judgment conditions when the target specified time period expires. Specifically, the actual timeout result includes no response (no message received) and partial response (partial message received but failed to form a complete boundary within the specified time).

[0120] Here, the target response transfer condition refers to the comparison and judgment branch pre-selected from all response binding image records associated with the current test task based on the actual generated response status (complete response or timeout).

[0121] For example, the actual response is monitored in real time within the target specified time period. If the actual response meets the complete response judgment condition before the timeout, the actual response is defined as the complete response boundary, and a complete and resolvable response result (actual response result) containing information such as response code is determined accordingly. If the complete response judgment condition is not met until the end of the target specified time period, the status is recorded as the actual timeout result, that is, the task has timed out is recorded as the actual timeout result.

[0122] It should be understood that the dual constraints of physical boundaries (complete response judgment conditions) and time boundaries (preset response timeout duration) ensure that subsequent logic judgments are based on accurate, complete, or explicit timeout feedback, avoiding logic confusion caused by incomplete response data or excessive waiting time, thereby improving the reliability of chip testing.

[0123] For example, based on the actual response result generated (whether it is a complete response or a timeout), branches with matching characteristics (target response transition conditions) are filtered from each response-bound mirror record. For instance, if the actual response result is that the task has timed out, only target response transition conditions that use the timeout result as the judgment content are filtered out, while branches that use the response code as the judgment condition are ignored.

[0124] It should be understood that by pre-screening the target response transition conditions, the scope of logical comparison is narrowed, ensuring that subsequent comparison operations are performed in a semantically consistent dimension (such as state to state, response code to response code), thereby improving chip testing efficiency.

[0125] For example, the actual response result (such as the actual response code or the actual timeout result) is compared with the pre-selected target response transfer conditions. Based on the success or failure of the comparison result, combined with the next execution node identifier information saved in the response binding image record, the next execution node is finally selected. Based on this, the complex timing logic (whether a timeout occurs) and business logic (what the response content is) are effectively integrated, ensuring that no matter whether the chip is in a normal response or abnormal timeout state, the corresponding logic exit can be found, thereby realizing closed-loop testing of the entire path.

[0126] Furthermore, if the actual response meets the complete response judgment condition bound to the current test task, the complete response completion time is recorded, and the completion time of the sent data of the current test task is subtracted from the complete response completion time to obtain the actual response delay of the current test task, which is then compared with the upper limit of the response delay of the current test task to determine the chip test result.

[0127] For example, if a complete response is not formed after a preset response timeout period since the completion of sending the data in the current test task, a partial response record or a no-response record is saved based on the received response data (such as response messages), and the target response transfer condition with timeout result as the judgment content is searched in the response binding mirror record of the current task. When a complete response is formed, the response code, key flags, and response data fields are read from the complete response (i.e., the actual response), and the current test task is recorded as not timed out; if a complete response is not formed after the preset response timeout period, the actual timeout result is recorded, and the response code, key flags, and response data fields, which can only be obtained from the complete response, are not read.

[0128] In the aforementioned testing method for the sensing and control chip, by setting a target specified time period, the problem of data interruption caused by signal interference and network latency can be effectively handled, ensuring that the response boundary judgment remains reliable even in non-ideal communication environments, thereby improving the reliability of chip testing. In addition to focusing on normal complete response jumps, a jump path based on timeout results has also been specifically established, which can reproduce the real protection, retry, or recovery logic triggered by the chip under test in actual scenarios due to slow response and link interruption. This significantly enhances the ability to capture potential reliability risks of the chip under test, thereby improving the reliability of chip testing.

[0129] Based on any of the above embodiments, in this method, determining the actual response result of the current test task based on the actual response includes:

[0130] The actual response result of the current test task is determined based on the actual response and the current number of consecutive retries for the current test task.

[0131] Here, the current consecutive retries count refers to the cumulative number of times the current test task has been logically triggered to repeat execution due to the previous execution not receiving the expected response. In a specific embodiment, this current consecutive retries count is maintained in real time by a retry counter corresponding to the current test task, and the counter is incremented each time execution is repeated.

[0132] Here, the actual response result refers to a composite status value that combines two dimensions: response data content / timeout status and execution history (number of retries). This value is used as the final input and matched against the target response transition conditions to determine the next execution node.

[0133] For example, when the current test task is executed and a complete response is generated, not only are data such as response codes and key flags extracted from the actual response, but the current number of consecutive retries is also read from the retry counter simultaneously.

[0134] It should be understood that this embodiment can distinguish between two different business states: success on the first attempt and success after multiple retries. Since the chip under test may need to retries to complete networking or communication under certain extreme environments, this embodiment ensures that different subsequent task paths can be selected based on the number of retries (for example, a chip that succeeds after multiple retries may enter the performance stability verification branch, while a chip that succeeds on the first attempt may enter the regular business branch), thereby improving the distinguishability of chip testing and thus improving the accuracy of chip testing.

[0135] The determination of the actual response result of the current test task based on the actual timeout result of the task having timed out includes:

[0136] Based on the actual timeout result and the current consecutive retries of the current test task, the actual response result of the current test task is determined.

[0137] For example, in the event of a task timeout (including no response and partial response), the timeout status flag is bound to the current number of consecutive retries. For instance, if the current test task timed out due to the failure of the second retry, the generated actual response result includes the two key pieces of information: timeout and the number of retries being 2.

[0138] It should be understood that this embodiment provides a basis for determining the retry termination logic. By combining the timeout status with the count value, the retry limit setting in the target response transfer condition can be precisely matched (if the number of retries has not reached the limit, it jumps back to the current task; if the limit has been reached, it jumps to failure termination). This avoids the waste of test resources caused by blind retries, ensures that the test process is fully aligned with the retry mechanism defined in the chip communication protocol, and thus significantly improves the rigor of chip testing.

[0139] The above-mentioned testing method for the sensing and control chip can not only reproduce simple sequential logic, but also complex loop paths (i.e., retry loops), thereby realistically simulating the service recovery process of the chip under test under unstable links, and thus improving the reliability of chip testing.

[0140] Based on any of the above embodiments, in this method, determining the next execution node based on the comparison results of the actual response result with each of the target response transition conditions and the identification information of each of the next execution nodes includes:

[0141] If only one of the target response transfer conditions successfully matches the actual response result, the next execution node is determined based on the next execution node identifier information indicated by the response binding mirror record associated with the target response transfer condition.

[0142] If all the target response transition conditions fail to match the actual response results, the response processing is determined to be missing and the test is terminated.

[0143] If at least two of the target response transition conditions are successfully compared with the actual response result, a response transition condition conflict is determined and the test is terminated.

[0144] For example, a successful comparison means that the actual response result generated by the chip under test (including response code, key flag bits, actual timeout result, current number of consecutive retries, etc.) fully meets the judgment range or value requirements set by a certain target response transfer condition.

[0145] Here, "missing response processing" means that the actual response result from the chip under test was obtained, but no response transition condition in the response binding image records matches it. This usually means that the executable test load image failed to cover all legitimate or abnormal response branches generated by the chip.

[0146] Here, a response transition condition conflict refers to a situation where an actual response generated by the chip under test simultaneously satisfies the response transition conditions set by two or more response binding image records. This typically means that there is overlap or ambiguity in the executable test workload images, making it impossible to uniquely determine the next execution node.

[0147] Here, "termination of test" refers to invalid termination of the test, meaning that the test cannot continue due to logical defects (missing or conflicting elements) in the executable test load image itself, rather than directly determining that the chip is unqualified.

[0148] For example, after performing the comparison operation, the number of target response transition conditions that meet the criteria is counted. If, among all the target response transition conditions, exactly one successfully matches the actual response result, then that matching result is determined to be the unique valid path. Subsequently, the identification information of the next execution node indicated in the unique matching record (such as the task number or termination code) is extracted, driving the test process to the next node. In other words, only when all the target response transition conditions indicated by a response binding mirror record are met is the next task number read from that response binding mirror record.

[0149] It should be understood that this embodiment eliminates the randomness of logic selection, ensuring that the chip under test always executes along a preset single path under a specific response, thereby ensuring compliance with consistency requirements.

[0150] For example, if after traversing all target response transition conditions, it is found that no record matches the current actual response result (such as an undefined response code or an unexpected timeout), it is determined that the response processing is missing. At this time, the identification information of the current test task and the unmatched response parameters in the actual response result will be recorded immediately, and the test termination operation will be executed. That is, when all the response transition conditions of no response-bound mirror record are met, the selection of the next execution node will stop, the identification information of the current test task, the complete response or timeout result, the unmatched response code, key flags and the current number of consecutive retries will be recorded, the response processing is missing will be output, and the test will enter invalid termination.

[0151] It should be understood that this embodiment can promptly identify coverage vulnerabilities in executable test load mirroring logic. By terminating the test rather than blindly declaring the chip a failure, it effectively distinguishes between chip anomalies and missing test mirror definitions, providing clear feedback for subsequent correction of the test load mirror and improvement of test coverage, thereby enhancing the reliability and accuracy of chip testing.

[0152] For example, if the actual response result simultaneously triggers two or more contradictory or parallel target response transition conditions, it will be identified as a response transition condition conflict. To prevent the test logic from entering an uncontrolled state, the selection of the next execution node will be stopped, a mirror condition conflict record will be output, and the test will terminate. In other words, when the response transition conditions of two or more responses bound to mirror records are simultaneously met, a mirror condition conflict will be output, and the test will terminate due to invalidity.

[0153] It should be understood that this embodiment avoids the risk of path deviation caused by overlapping mirror logic by forcibly terminating the logic, thereby ensuring that the test path of each chip is based on clear and mutually exclusive logic branches in the complex chip business flow, thereby improving the reliability and accuracy of chip testing.

[0154] In the aforementioned testing method for the sensor-controlled chip, real-time monitoring of two abnormal logical states—missing response processing and conflicting response transfer conditions—ensures that the next execution node is determined only when the logic is completely closed, thus outputting the chip test result. This avoids misjudgments or omissions caused by logical defects in the test program itself, thereby improving the reliability and accuracy of chip testing. Furthermore, by uniquely determining a single next execution node, the randomness of logic selection is eliminated, ensuring that the chip under test always executes along a preset single path under a specific response, thus ensuring compliance with consistency requirements and further improving the reliability and accuracy of chip testing.

[0155] Based on any of the above embodiments, in this method, any of the response binding image records is further used to record dynamic field references bound to the current test task; after the step of determining the next execution node based on the actual response generated by the chip under test executing the current test task and each of the response binding image records, the method further includes:

[0156] When the next execution node is the next test task, the dynamic field is obtained based on the dynamic field reference indicated by the response binding mirror record that is jointly associated with the current test task and the next test task;

[0157] Based on the dynamic field, the sending data for the next test task is generated.

[0158] The dynamic fields mentioned above are fields that change dynamically during the testing process. Dynamic fields are fields whose values ​​cannot be fixed to the historical values ​​of the baseline chip during test execution, but must be dynamically updated based on the real-time response of the chip under test; for example, session identifiers, link identifiers, task identifiers, or specific service data numbers generated in real time by the chip under test.

[0159] Here, dynamic field references refer to a set of mapping rules stored in the response binding mirror record, used to indicate the source of dynamic fields and their conversion methods. These dynamic field references may include, but are not limited to, at least one of the following: source task identification information (such as the source task number), the position and length of the source response data field in the complete response, the position and length of the target field in the sent data (such as the sent message), and conversion parameters such as byte order, encoding, bitmask, truncation, or concatenation.

[0160] Here, "transmitted data" refers to the instruction data (such as an instruction message) prepared to be sent to the chip under test for the next test task. In one specific embodiment, the transmitted data consists of a fixed transmission field and a dynamically filled dynamic field, and the length field and checksum are updated according to the chip communication protocol requirements.

[0161] For example, during the initial test load image construction phase, by tracing the application's assignment logic in reverse, it is possible to identify which sent fields depend on the responses of preceding tasks. These dependencies are then stored as dynamic field references in the response binding image record along with the response transition conditions. This means that each logical jump path carries the corresponding data population rules.

[0162] For example, after determining to proceed to the next test task, the dynamic field references in the associated record are parsed to locate the actual complete response of the preceding specific task. The source response data field is read from the specified position of this actual complete response and converted strictly according to the byte order, encoding method, bitmask, or truncation rules recorded in the reference, thereby obtaining the dynamic field value applicable to the current chip state. That is, for each dynamic field in the transmission message of the next test task, the source task identification information (such as the source task number), the position and length of the source response data field, the target field position, and the field conversion rules are read from the response-bound mirror record; then, according to the source task identification information, the complete response of the corresponding task is found in the preceding complete responses already formed in the current test of the chip under test; the source response data field is read from the specified position; byte order adjustment, bitmasking, truncation, concatenation, or encoding conversion is performed; and the conversion result is written to the target field of the transmission message of the next test task.

[0163] It should be understood that this embodiment eliminates interference from outdated data in the historical logs of the benchmark chip. By extracting data directly from the actual response of the chip under test, it ensures that dynamic fields such as session identifiers are fully aligned with the chip's current operating state, avoiding communication handshake failures due to data invalidation, thereby improving the reliability of chip testing.

[0164] For example, the obtained dynamic field values ​​are filled into the target positions of the transmission message template for the next test task. After all dynamic fields have been written, the length field, checksum, or cyclic redundancy check field in the transmission message are recalculated and updated according to the chip communication protocol, ultimately generating valid transmission data.

[0165] It should be understood that this embodiment achieves closed-loop generation of message content. Through dynamic padding and automatic updates of protocol verification, it ensures that each sent message is not only correct in business logic but also legal at the protocol encapsulation level. This enables the test equipment to truly simulate the behavior of the original application and engage in deep logical interaction with the chip under test, thereby improving the reliability of chip testing.

[0166] In the above-mentioned testing method for the sensory control chip, the subsequent data to be sent is constructed by referencing the actual response field of the chip under test in real time. This solves the technical problem in the prior art where the message content (such as expired session identifiers) is not recognized by the chip due to fixed replay logs. It ensures the simultaneous consistency between the test path and the data sent, eliminates the data misalignment between the test process and the chip status, and thus improves the reliability of chip testing.

[0167] Based on any of the above embodiments, after the step of generating the sending data for the next test task based on the dynamic field, the method further includes:

[0168] If the first verification result and / or the second verification result pass the verification, the data to be sent is sent.

[0169] The first verification result is determined by comparing the identification information of the next actual test task to be executed with the identification information of the next test task indicated by the response binding mirror record that is jointly associated with the current test task and the next test task. The second verification result is determined by comparing the expected byte sequence with the actual filling value of the dynamic field in the sent data. The expected byte sequence is generated based on the dynamic field reference and field conversion rules indicated by the response binding mirror record that is jointly associated with the current test task and the next test task.

[0170] Here, the first verification result refers to the result of checking the correctness of the test flow jump logic. Its core is to verify whether the next action to be executed by the test program is completely consistent with the preset logical exit in the response binding image record.

[0171] Here, the second verification result refers to the result of checking the correctness of the dynamic field content in the sent data. Its core is to verify whether the byte sequence filled in the key positions of the sent data accurately restores the relevant fields in the preceding response.

[0172] Here, the expected byte sequence refers to the theoretically correct value generated by re-extracting and transforming the actual response data of the source task from the dynamic field references (including position, length, and transformation parameters).

[0173] Here, the actual padding value refers to the actual byte sequence that has been written to the target field position in the send buffer or send data template.

[0174] For example, before executing the next test task, the currently determined actual task number is compared with the preset next task number in the uniquely matched response binding image record. Only when the two are completely identical is the first verification considered successful.

[0175] It should be understood that, due to the possibility of interference such as memory overflow and logic race in complex testing environments, the first verification can promptly detect and prevent task misalignment caused by faults in the testing system itself, ensuring that the system always interacts with the chip under test according to the correct path defined in the image, thereby improving the reliability of chip testing.

[0176] For example, based on the source task number indicated by the response binding mirror record, the original data of the preceding actual response is reread, and the expected byte sequence is regenerated according to field conversion rules (such as byte order adjustment, bitmask, etc.); then, the expected byte sequence is compared byte by byte with the actual padding value at the corresponding position in the sent data.

[0177] It should be understood that this embodiment ensures the absolute accuracy of dynamic fields during extraction and conversion, eliminating potential errors in the data processing stage. Through independent recalculation and comparison, it can promptly identify data deviations caused by encoding inconsistencies or misreading of offsets, ensuring that the data sent to the chip truly reflects the chip's current operating status, thereby avoiding invalid communication and improving the reliability of chip testing.

[0178] For example, the communication interface is only allowed to officially send the data if both the first and second verification results show that the verification has passed. If either verification fails, the output mirror will be misaligned and the test will enter an invalid termination state.

[0179] It should be understood that sending commands only after mandatory verification greatly reduces the risk of false tests due to incorrect configuration of the executable test load image or abnormal operation of the test program, ensuring that every command sent is based on the current state of the chip under test and is logically self-consistent.

[0180] For example, before sending data for the next test task, a next task number verification (first verification) and a dynamic field padding value verification (second verification) are performed respectively. The next task number verification compares the next task number that the test program is preparing to execute with the next task number saved in the uniquely matching response binding mirror record. The dynamic field padding value verification rereads the actual complete response of the source task, regenerates the expected byte sequence according to the field positions and field conversion rules saved in the response binding mirror record, and then compares the expected byte sequence with the actual padding value of the target field in the data sent by the next test task. If the actual padding value differs from the expected byte sequence in the number of bytes, or if the number of bytes is the same but any corresponding byte is different, the dynamic field padding value verification is deemed to have failed. Only after both verifications pass is the data for the next test task sent.

[0181] Understandably, the next test task and the next message content are both determined by the actual response of the chip currently under test. For example, a complete network response returns the session identifier of the current chip. When subsequent service messages need to carry this identifier, the test program retrieves the value from the specified field of the current chip's response and writes it into the target field according to the chip's communication protocol, without copying the session identifier of the reference chip.

[0182] In the above-mentioned testing method for the sensor-controlled chip, the above verification ensures that all transmitted data is free of logical and content errors, eliminating test failures caused by problems with the testing equipment or the image itself. This allows for a more definitive determination that the chip itself is defective, significantly improving the credibility of the chip test results, i.e., improving the reliability of the chip test.

[0183] Based on any of the above embodiments, in this method, the actual response is generated based on the response data belonging to the current test task; during the testing process of the chip under test, the method further includes:

[0184] Upon obtaining new response data, the new response data is compared with the attribution criteria of the response data of each incomplete task in the incomplete task set.

[0185] If the new response data is successfully matched with the response data of only one incomplete task in the set of incomplete tasks, the new response data will be assigned to the incomplete task that was successfully matched.

[0186] If the new response data is successfully matched with the response data attribution criteria of at least two incomplete tasks in the set of incomplete tasks, the new response data is determined to be response attribution conflict data.

[0187] If the new response data fails to match the attribution criteria of the response data of all incomplete tasks in the incomplete task set, the new response data is determined to be unattributable data.

[0188] Here, the response data belonging to the current test task are the data generated by the chip under test when executing the current test task, such as response messages.

[0189] Here, new response data refers to newly acquired response data. In one specific embodiment, new response data refers to a single message or data fragment acquired in real time, which has not yet been associated with a specific test task.

[0190] Wherein, any of the unfinished tasks are tasks that have sent data but have not formed a complete response, and the current time has not exceeded the specified time period of the unfinished task; the specified time period of the unfinished task is a time period with the completion time of sending the sent data of the unfinished task as the start time and a preset response timeout duration as the time interval; the response data attribution condition of any of the unfinished tasks is used to indicate the conditions under which new response data belongs to the unfinished task.

[0191] Here, the incomplete task set refers to a dynamic list consisting of all test tasks that have sent data but have not yet formed a complete response and whose current time has not exceeded the preset response timeout period.

[0192] Here, the data already sent refers to the data that needs to be sent to begin executing the unfinished task, such as a sent message.

[0193] In one specific embodiment, the preset response timeout duration is the longest waiting time extracted from the receive waiting time or timeout judgment value set by the application for the current test task when generating the test load image. Further, if the mandatory response time specified by the chip communication protocol is shorter than this longest waiting time, the mandatory response time specified by the chip communication protocol is used as the preset response timeout duration.

[0194] Here, the response data attribution condition refers to the protocol field feature used to determine which test task a new response data should belong to. This response data attribution condition may include, but is not limited to, at least one of the following: node identifier, session identifier, message type, and frame sequence number. The response data attribution condition can specify a single value (such as a specific session identifier) ​​or a range of values.

[0195] Here, conflicting response data refers to an abnormal state where, due to chip protocol design flaws or test environment interference, a new response data simultaneously meets the response data attribution conditions of two or more incomplete tasks.

[0196] Here, "unassignable data" refers to new response data that does not meet the attribution criteria for response data of any task in the current set of incomplete tasks. Specifically, it usually indicates that the new response data is an active reporting message from the chip or an unexpected interference message.

[0197] For example, upon receiving each new response data, its protocol fields (such as session identifier and node identifier) ​​are sequentially compared with the response data attribution criteria of each incomplete task in the incomplete task set. This process is performed within a valid window limited by a preset response timeout duration, ensuring that the comparison objects are all currently active incomplete tasks. In other words, upon receiving a response, the received new response data is assigned to the corresponding incomplete task according to the saved response data attribution criteria; if it is a fragmented response, it is reassembled according to the determined fragmentation grouping, arrangement, and connection rules.

[0198] For example, for interleaved responses, a set of incomplete tasks is maintained, consisting of test tasks that have been sent but have not yet formed a complete response and have not timed out. Upon receiving a new message (new response data), its node identifier, session identifier, message type, and frame sequence number are sequentially compared with the response message attribution conditions (response data attribution conditions) of each incomplete task. For tasks requiring consecutive frame sequence numbers, when no response message has been received, the starting frame sequence number specified by the chip communication protocol or recorded in the field communication log is used; when a response message has been received, the frame sequence number of the last attribution message plus one is used as the frame sequence number to be compared, and the count restarts from zero after exceeding the maximum frame sequence number allowed by the protocol. If a new message satisfies all the attribution conditions of only one incomplete task, it is assigned to that incomplete task; if none are satisfied, it is recorded as an unassignable message; if it satisfies two or more tasks simultaneously, it is recorded as a response attribution conflict. Specifically, when an actively reported message is defined by the chip communication protocol or application as a response or status event of a sent task, it is assigned to the corresponding task according to the same rules.

[0199] It should be noted that when the response data attribution condition specifies a single value, the corresponding fields are checked for equality; when a range of values ​​is specified, the data is checked for whether it falls within that range. Fields not specified are not included in the comparison.

[0200] For example, for fragmented responses, when the chip communication protocol sets a fragment group identifier, new response data (messages) with the same node identifier, session identifier, message type, and fragment group identifier are grouped into the same group; when no fragment group identifier is set, messages belonging to the same incomplete task, with the same node identifier, session identifier, and message type, and consecutive frame sequence numbers from the first fragment to the last fragment are grouped into the same group. When the protocol sets a byte offset field, the fragments are arranged in ascending order of byte offset; when no byte offset field is set but a fragment sequence number is set, the fragments are arranged in ascending order of fragment sequence number; when both exist simultaneously, the two arrangements are first checked for consistency; if inconsistent, a position conflict is recorded and reassembly is stopped. Subsequently, missing fragments and duplicate fragments are checked, duplicate protocol headers are removed, and the data portion is connected. After all fragments are complete, the response code, running status, link identifier, task identifier, retry sequence number, recovery identifier, and chip return data are extracted from the reassembled complete response.

[0201] It should be understood that this embodiment can handle feedback from the chip in a multi-task interleaved execution state. Since the chip under test often does not return a response immediately after sending, or the responses of multiple test tasks overlap in time, an independent data receiving channel is established for each incomplete task through logical condition filtering, thereby enabling asynchronous communication.

[0202] For example, when new response data successfully matches only one incomplete task in the set of incomplete tasks, the new response data is stored in the receive buffer of that incomplete task. These response data belonging to the same task will then be merged according to the fragmentation and reassembly rules to generate the actual response for that task.

[0203] It should be understood that this embodiment prevents data contamination between tasks. Through a strict single matching rule, it ensures that the response data obtained by each test task is directly related to the instruction it issued (i.e., the data sent), thereby providing highly reliable data support for subsequent node switching based on the actual response, and thus improving the reliability of chip testing.

[0204] For example, if new response data matches multiple incomplete tasks simultaneously, or does not match any incomplete tasks at all, it will be marked as a response attribution conflict or unattributable, respectively. The original bytes and timestamp of such new response data are recorded, and invalid termination tests are performed if necessary.

[0205] It should be understood that this embodiment can capture abnormal states in the communication link in a timely manner; identifying conflicting response data helps to discover logical vulnerabilities in the chip's multi-connection management; identifying unassignable data helps to capture unexpected proactive reporting by the chip, thereby avoiding logical misalignment caused by misjudging irrelevant messages as task responses, and thus improving the reliability of chip testing.

[0206] In the aforementioned testing method for the sensor-controlled chip, the above approach ensures that each incomplete task can construct a correct actual response, thereby improving the reliability of chip testing. Furthermore, by dynamically comparing data within a preset response timeout window, expired response data is automatically removed and active response data is quickly categorized, ensuring that each incomplete task can construct a correct actual response, thus further improving the reliability of chip testing.

[0207] Based on any of the above embodiments, such as Figure 2 As shown, the executable test load image is generated based on the following steps: 201, 202, 203 and 204.

[0208] Step 201: Generate multiple mirror task units based on the field communication logs of the preset business process executed by the benchmark chip.

[0209] Here, the benchmark chip refers to a chip that has passed basic electrical and functional checks and can normally execute the predetermined business process in an FT (Final Test) environment or target application device. The interaction data it generates is used as the original reference for generating the test load image.

[0210] The preset business process includes multiple test tasks executed sequentially, and the field communication log is a communication log of communication with the benchmark chip.

[0211] Here, the field communication log refers to the actual response of the chip and network when performing a test load mirroring on the chip under test, and the field refers to the communication process formed by the chip during testing.

[0212] Here, a mirrored task unit refers to a structured description record of a single test task in a preset business process. This mirrored task unit may include, but is not limited to, at least one of the following: task identification information (such as task number), original sent message, sending trigger condition, response data attribution condition, complete response determination condition, and response data fields (dynamic fields).

[0213] For example, a reference chip is selected to execute a predetermined business process, collecting field communication logs containing message direction, raw bytes, timestamps, node identifiers, and frame sequence numbers. The field communication logs are parsed according to the communication protocol, with each transmission action serving as a task starting point. The attributes of each field are extracted to generate multiple mirror task units.

[0214] More specifically, a benchmark chip that has passed basic electrical and functional checks is selected, and a predetermined business process is executed in the FT environment or target application device, while collecting field communication logs. The field communication logs must record at least the message direction, raw bytes, timestamp, communication channel, node identifier, session identifier, and frame sequence number, and simultaneously save the chip communication protocol, application message sending and receiving rules, message construction code, and branch execution code. Firmware burning is a subtask of the power-on startup task; if firmware burning is not required, this subtask enters the burned confirmation branch. The sent messages, response messages, and chip-initiated reporting messages in the field communication logs are parsed according to the communication protocol, and the message type, node identifier, session identifier, frame sequence number, length field, fragment position, end flag, and response data field are extracted from the protocol fields of each message. Starting with a single sending action, a unique task number is assigned to this task. The original sent message, the position and value of fixed sending fields, the sending trigger condition, the sending time interval, the response data attribution condition, the complete response determination condition, and response data fields (dynamic fields) that may affect subsequent tasks or messages are recorded. If a task is not triggered by a sending task but will cause the application to send subsequent messages or select subsequent tasks, a mirrored task unit is established using the receiving action of this actively reported message as the task starting point; otherwise, only logs are saved. Finally, the task number, original sent message, position and value of fixed sending fields, sending trigger condition, sending time interval, response data attribution condition, complete response determination condition, and response data fields are written to a mirror file to form a mirrored task unit.

[0215] Among these, fixed transmission fields are protocol headers, command words, fixed addresses, or fixed parameters that remain the same for each execution. When an application reads a field from the complete response and uses its value to select the next test task, generate subsequent transmission messages, or control retries, switching, resumption, or termination, it records that field as a response data field. The response data field can be directly written into subsequent transmission messages, or it can be written into subsequent transmission messages after performing truncation, concatenation, encoding, or bitwise operations.

[0216] It should be understood that transforming unstructured raw message sequences into independently schedulable logical units (mirror task units) with identifiable rules provides data model support for subsequent accurate response determination for each test task.

[0217] Step 202: Based on the execution data of the preset business process executed by the benchmark chip, generate a binding image record between each of the test tasks.

[0218] In this context, any of the aforementioned binding image records is used to record the binding relationship between two test tasks.

[0219] Here, the binding image record refers to the response binding image record mentioned above. It is a record used to describe the logical evolution relationship between test tasks. It records the transition conditions from the current test task to the next test task or the termination result, as well as the data dependencies between tasks (such as dynamic field references).

[0220] For example, by analyzing the application execution data (such as source code logic or firmware image instructions) that controls the business process, the jump branches of each test task under different response states are extracted. Each bound image record accurately records the logical triggering relationship and field reference relationship between two test tasks.

[0221] It should be understood that this embodiment establishes logical edges between tasks, realizing the key leap from static message replay to dynamic state machine transformation. By recording and binding mirror records, it ensures that the test load mirror not only includes what is sent, but also the decision logic of why it jumps.

[0222] Step 203: Based on the multiple image task units and each of the bound image records, generate an initial test load image.

[0223] Here, the initial test load image refers to the preliminary test data set that has completed task unit modeling and logical relationship binding, but has not yet undergone path reachability verification, condition mutual exclusion check, and physical test condition solidification.

[0224] In one embodiment, multiple generated image task units are used as nodes and associated with each other by binding image records. Power-on startup is set as the entry task, and all image task units and bound image records are integrated into a structured image file, forming the initial test load image. Based on this, a closed-loop test data set is formed, enabling the test equipment to perform path retrieval and data extraction in a complex task tree, providing a logical framework for subsequent automated testing.

[0225] Step 204: If the initial test load image passes the check, the encapsulation test conditions are written into the initial test load image to generate the executable test load image.

[0226] Here, the packaging test conditions refer to the external physical constraint parameters required for a specific chip packaging batch, which may include, but are not limited to, at least one of the following: supply voltage (e.g., 3.3V), ambient temperature, master-slave node configuration ratio, and communication rate minimum (e.g., 10Mbps).

[0227] For example, after the path reachability, condition mutual exclusion and field availability checks of the initial test load image pass, the preset packaging test conditions (such as voltage range, FT yield index, etc.) are solidified into the image file (initial test load image), and finally an executable test load image that can be loaded and executed by the test machine is generated.

[0228] It should be understood that this embodiment ensures that the generated image meets the compliance constraints of actual production. By solidifying the packaging test conditions, the same logic image can be fine-tuned for the requirements of different packaging batches, enhancing the applicability and flexibility of the test load image in chip batch screening.

[0229] The aforementioned testing method for the sensing and control chip addresses the limitation of existing technologies where fixed-sequence test loads cannot cope with changes in chip state by deeply analyzing and logically binding field communication logs. This provides a highly reliable logical foundation for adaptive chip testing. Furthermore, the hierarchical modeling approach allows complex communication protocols and pre-defined business processes to be quickly converted into structured image files, shortening the transformation cycle from application development to FT mass production testing and enabling efficient reuse of test resources, thereby improving chip testing efficiency.

[0230] Based on any of the above embodiments, in this method, the initial test load image is checked based on at least one of the following methods:

[0231] Perform mutual exclusion checks on any two response transition conditions bound to the same test task;

[0232] Based on the initial test load image, at least one test reachable path is determined; path checks are then performed on each of the at least one test reachable path.

[0233] Check the availability of the dynamic response fields for each of the test reachable paths.

[0234] Here, the mutual exclusion check pointer performs logical exclusive verification on multiple response transition conditions associated with the same test task. Its purpose is to ensure that for any actual response result, at most one response transition condition can be matched, thereby eliminating logical ambiguity.

[0235] Here, the test reachable path refers to the sequence of tasks in the initial test load image that, starting from the power-on startup entry task, expands layer by layer through the response binding image records, and can sequentially reach subsequent task units or termination results.

[0236] Here, path checking refers to the verification of the completeness, validity, and loop status of the test reachable path. In one specific embodiment, path checking includes checking whether the path can reach the successfully terminated or failed terminated node normally, and whether there are any illegal loops with no upper limit.

[0237] Here, the availability of dynamic response fields refers to verifying whether the dynamic fields required by subsequent tasks in a specific test reachable path actually exist in the corresponding source task execution sequence and can be correctly extracted.

[0238] For example, a detailed comparison is performed on any two response transition conditions bound to the same test task. The comparison includes: whether there is an intersection in the response code sets, whether the required values ​​of key flag bits are opposite, whether timeout status requirements conflict, and whether the corresponding consecutive retries intervals overlap. If there is no conflict in any of these dimensions, the two response transition conditions are considered mutually exclusive. Based on this, it is ensured that the test equipment can make a unique and definite path decision when facing chip responses during execution. By eliminating condition overlaps in the offline stage, mirror condition conflict anomalies that may occur during online testing are effectively prevented, ensuring the stability of the test process and thus improving the reliability of chip testing.

[0239] More specifically, a mutual exclusion check is performed on any two response transition conditions under the same test task, and the specific comparison is as follows:

[0240] For response codes, first, according to the response code value range specified by the chip communication protocol, convert the equal to, not equal to, value range, or enumerated values ​​in each response transition condition into a set of response codes allowed by that response transition condition. Then, calculate the intersection of the two response code sets. If the intersection is empty, the two conditions cannot be satisfied simultaneously by the same response code; if the intersection is not empty, the response codes in the intersection are those allowed by both conditions. When a response transition condition does not restrict response codes, all response codes allowed by the chip communication protocol are taken as the set of response codes allowed by that response transition condition.

[0241] For critical flag bits, read the bit positions and required values ​​of each bit checked by the two response transfer conditions. When two response transfer conditions check the same bit, if one requires the bit to be 0 and the other requires it to be 1, then the two response transfer conditions cannot be satisfied simultaneously on that bit; if the required values ​​are the same, then the two response transfer conditions can be satisfied simultaneously on that bit. When two conditions check different bits, retain their respective bit value requirements; as long as there is no case where the required value for the same bit is opposite, it is considered that the two response transfer conditions do not contradict each other regarding the critical flag bits. When a response transfer condition does not check a critical flag bit, that response transfer condition does not restrict the value of the critical flag bit.

[0242] For timeout states, check whether both response transfer conditions have timeout checks. Response transfer conditions can require the current task to time out, require the current task not to time out, or not use timeout as a condition. When one response transfer condition requires a timeout and the other requires no timeout, the two response transfer conditions cannot be simultaneously satisfied by the execution result of the same test task; except in this case, the two response transfer conditions do not conflict in terms of timeout states.

[0243] For the number of retries, first convert each response transition condition into an integer closed interval within the range of 0 to the retry limit. Then, let the retry interval corresponding to the first response transition condition be [a1, b1], and the retry interval corresponding to the second response transition condition be [a2, b2]. When a1 is greater than or equal to a2, assign L the value of a1; when a1 is less than a2, assign L the value of a2. When b1 is less than or equal to b2, assign U the value of b1; when b1 is greater than b2, assign U the value of b2. When L is less than U, the two intervals contain more than two identical integer retries; when L is equal to U, the two intervals contain only one identical integer retries; when L is greater than U, the two intervals do not contain identical retries. When a response transition condition does not limit the number of retries, use 0 to the retry limit as the retry interval corresponding to that response transition condition.

[0244] When two response transition conditions have the same response code, do not have opposite values ​​for the same key flag, do not conflict with each other regarding timeout requirements, and contain at least one identical integer in their respective retry intervals, it indicates that an actual response result can simultaneously satisfy both response transition conditions, and these two response transition conditions are recorded as condition overlap. If any of the above conditions are not met, the two response transition conditions are mutually exclusive.

[0245] For example, mirrored task units are treated as nodes, and mirrored records are bound as directed edges. All possible task sequences are expanded layer by layer from the entry test task. During path checking, isolated paths that cannot reach the termination node are identified and marked, and retry paths are expanded. For paths with return relationships, the retry limit specified by the application is checked to determine if there are any infinite loops that cannot be terminated. Based on this, it is ensured that each test branch defined in the mirror is meaningful and controlled. By identifying and eliminating logically isolated points or illegal loops, it is guaranteed that the test load mirror can guide the chip under test to a definite test conclusion, improving the efficiency of automated testing.

[0246] For example, for each test reachable path, the validity of dynamic field references is checked one by one. The checks include: whether the source task, as the data source, has been executed and formed a complete response in the current path sequence before entering the target task; whether the position and length of the source response data fields exceed the response boundaries; and whether transformation parameters such as bitmasks and truncation rules are within the valid range. Based on this, data gaps are prevented. Through path-level availability verification, it is ensured that every referenced dynamic field is verifiable during real-time population in complex jump processes, thereby avoiding test interruptions caused by referencing empty or out-of-bounds data and ensuring the reliability of chip testing.

[0247] More specifically, the availability of each dynamic field in each test reachable path is checked, including: the source task has been executed and formed a complete response before entering the target task; the position and length of the source response data fields do not exceed the complete response; the bitmask and truncation range do not exceed the source response data fields; all concatenated fields exist and their total length equals the target field length; the number of bytes after encoding equals the target field length; and each response message type that can enter the current condition contains the required fields. When a task with the same number is executed multiple times, the most recent complete response before the target task was sent is referenced by default. When the application saves and calls the response data of an earlier executed task, the dynamic fields are checked according to the complete response actually called by the program, and the most recent complete response is not used as a substitute.

[0248] The aforementioned testing method for the sensor-controlled computing chip addresses the problem in existing technologies where test program defects are often only discovered during batch testing by performing rigorous logic and data verification before the image is officially distributed. This significantly reduces the invalid alarm rate in chip testing and improves chip testing efficiency. Furthermore, through the synergistic effect of mutual exclusion checks, path checks, and availability checks, it ensures that the executable test load image is a logically consistent and data-closed-loop instruction set, thereby ensuring the reliability of chip testing.

[0249] Based on any of the above embodiments, in this method, any of the bound mirror records is used to record dynamic field references, which are used to determine dynamic response fields. The dynamic field references are determined by determining the source of the dynamic response fields.

[0250] In one embodiment, determining the source of a dynamic response field involves analyzing program logic to ascertain the origin of non-fixed fields in transmitted data (such as sent messages). This means determining whether the field value originates from a program constant definition, external input, or specific response data returned by the chip in a preceding task.

[0251] For example, for fields in subsequent transmitted data (such as transmitted messages) that are not recorded as fixed transmission fields, the process traces backward from the field's position in the transmission buffer, along write statements, variable assignment statements, and evaluated expressions. When the application source code is available, all assignment branches related to the field are examined according to the variable's definition, assignment, and usage relationships; when only the compiled executable file or firmware image is available, the field's origin is traced backward from the instruction that writes to the transmission buffer, along the register or memory address used by that instruction.

[0252] Specifically, when the written value originates from a register or memory address, the program path leading to the write instruction is followed sequentially backward to find the corresponding register assignment instruction or the corresponding memory address write instruction. When encountering data copying, byte order adjustment, bitwise operations, truncation, concatenation, or encoding, the processing method and parameters are recorded, and the input data is traced further. When encountering function calls or conditional jumps, the return path or branch path that could form the written value is checked. Tracing stops when a fixed value, unrecorded external input, or a memory area storing a complete previous response is reached. If the source is a complete previous response, the specific response data field is mapped according to the read position and length.

[0253] When a program constant is traced, the target field is added as a fixed sending field; when the response data field of the preceding mirror task unit is traced, the target field is identified as a dynamic field; if the source still cannot be determined, the position, length, and specific reason for not being able to determine the source of the target field are recorded, and the generation of executable records involving that field is stopped. Specific reasons include: the existence of two or more unavoidable assignment sources, the field value coming from unrecorded external input, or the inability to establish a correspondence between the data in the compiled program and the specific response data field.

[0254] The dynamic field reference stores the source task number, the position and length of the source response data field in the reassembled complete response, byte order, encoding method, bitmask, truncation or concatenation rules, and the position and length of the target field. Multi-byte fields are arranged according to the protocol specifications; when bitmasking, truncation, concatenation, or encoding processing is required, the corresponding mask value, start bit, field length, concatenation order, or encoding method is recorded, and the source response data field is converted according to the recorded processing method and parameters during mirroring.

[0255] The system reads the actual bytes of the source response data field from the field communication log, converts them according to the byte order, encoding method, bitmask, and truncation or concatenation rules recorded in the dynamic field reference, and compares the converted byte sequence with the target field of subsequent historical sent messages in the field communication log. If the lengths are the same and all bytes are identical, the dynamic field reference is retained; otherwise, other assignment statements, intermediate variables, and conditional branches at the same send buffer location are checked. The dynamic field is written to the target field location corresponding to the next task's send message template, or to the corresponding location of the send buffer where the message is to be sent. Then, the length field, checksum field, and cyclic redundancy check field are recalculated and updated according to the chip communication protocol. If the chip communication protocol does not set any of these fields, the generation or update process for that field is not performed.

[0256] In the above-mentioned testing method for the sensing and control chip, by determining the source of the dynamic response fields, it is ensured that each dynamic field referenced by the test load mirror is generated based on the chip's current real session or link state. This eliminates the interference of outdated data in the historical logs of the benchmark chip on the testing process, ensuring that the sent data can be correctly identified and responded to by the chip, thereby ensuring the reliability of the chip test.

[0257] Based on any of the above embodiments, in this method, the test execution record is used to record at least one of the following: the actual task path of the chip under test, the identification information of the first failed test task in the actual task path, and the response result of the first failed test task; the method further includes:

[0258] The batch test results are determined based on the test execution records and chip test results of multiple chips in the same package batch.

[0259] Here, the actual task path refers to all the test task nodes that the chip under test actually traverses in chronological order during the execution of the executable test workload image. This path reflects the specific jump process selected by the chip due to its own response differences, including the normal process, retry loop, and exception recovery path.

[0260] Here, the first failed test task refers to the specific test task unit that first fails to meet the pass / fail criteria (such as response timeout, response code error, abnormal key flag bit, response delay exceeding the limit, or communication rate not meeting the standard) during the effective testing process of the chip under test.

[0261] Here, the response result of the first failed test task refers to the initial response data that caused the chip to be judged as unqualified. It may include, but is not limited to, at least one of the following: the original message bytes at that time, the reassembled complete response content, the actual response latency, and the current number of consecutive retries, etc.

[0262] Here, batch test results refer to a comprehensive statistical conclusion drawn from all chips tested within the same package batch. Key metrics may include, but are not limited to: the number of valid tests, the number of qualified tests, the Fourier Transmission Rate (FT) yield, and the statistical distribution of failed tests.

[0263] For example, an independent test execution record is established for each chip participating in the test. This test execution record meticulously records the actual task path of the chip. When a chip under test fails, the identification information of the first failed test task and its corresponding response result are accurately identified and recorded. Simultaneously, the task number, termination type, first failure location, and failure mode are converted into a unified code for storage and associated with the chip serial number and packaging batch. Based on this, interference from subsequent secondary errors in determining the cause of failure can be eliminated. By locking onto the first failed task, the most direct logical entry point for failure physical analysis is provided, thereby significantly enhancing the accuracy of locating single-point faults in the chip and achieving data transparency in the chip-by-chip full inspection process.

[0264] For example, the test execution records of all individual chips within the same package batch are automatically aggregated. First, records of invalid and terminated tests are removed to determine the number of valid tests, and then the Fourier Transform (FT) yield is calculated. If the FT yield is lower than a preset threshold (e.g., 98%), the distribution frequency of the first failed task is further analyzed, and the chip pins, power supply networks, communication interfaces, and load board channels related to the failed tasks are queried. Based on this, systemic process defects or test environment anomalies can be identified. Through batch-level statistical analysis, concentrated failures of a particular task or pin within a specific batch can be discovered, thus providing quantitative evidence for process inspection on the packaging side and health assessment of the FT test load board, thereby improving chip testing efficiency.

[0265] In the above-mentioned testing method for the sensory control chip, the structured storage of the actual task path, the identification information of the first failed test task, and the response result of the first failed test task enables efficient management of massive test data. This allows for quality trend analysis across time and batches. Through closed-loop correction measures (such as correcting the image or restoring the test conditions), the consistency of chip testing and its quality traceability throughout the entire life cycle are ensured.

[0266] To facilitate understanding of the above embodiments, a specific embodiment will be described here. For example... Figure 3 As shown, firstly, a mirror task unit with complete response boundaries is generated. Specifically, the reference chip executes a predetermined business process, collects on-site communication logs, parses messages, and generates a mirror task unit.

[0267] More specifically, a benchmark chip that has passed basic electrical and functional checks is selected, and a predetermined business process is executed in the FT environment or target application device, while collecting on-site communication logs. The sent messages, response messages, and chip-initiated reporting messages in the on-site communication logs are parsed according to the communication protocol. Message type, node identifier, session identifier, frame sequence number, length field, fragment position, end flag, and response data field are extracted from the protocol fields of each message. Taking a single sending action as the starting point of the task, a unique task number is assigned to this task, and the following are recorded: the original sent message, the position and value of fixed sending fields, the sending trigger condition, the sending time interval, the response message attribution condition, the complete response determination condition, and the response data field that may affect subsequent tasks or subsequent messages.

[0268] For interleaved responses, a set of incomplete tasks is maintained, consisting of tasks that have been sent but have not yet formed a complete response and have not timed out. Upon receiving a new response message, its node identifier, session identifier, message type, and frame sequence number are compared sequentially with the response message attribution conditions of each incomplete task. Specifically, if the response message attribution condition specifies a single value, the corresponding fields are checked for equality; if a range of values ​​is specified, the message is checked for inclusion within that range; unspecified fields are not included in the comparison. For tasks requiring consecutive frame sequence numbers, if no response message has been received, the starting frame sequence number specified by the chip communication protocol or recorded in the field communication log is used; if a response message has been received, the frame sequence number of the last attribution message plus one is used as the frame sequence number to be compared, and the count restarts from zero if the maximum frame sequence number allowed by the protocol is exceeded. If a new response message satisfies all the response message attribution conditions of only one incomplete task, it is assigned to that incomplete task; if none are satisfied, it is recorded as an unattributable message; if it satisfies the conditions of two or more tasks, it is recorded as a response attribution conflict. When a proactively reported message is defined by the chip communication protocol or application as a response or status event of a sent task, it is assigned to the corresponding task according to the same rule; if it is not triggered by the sent task but will cause the application to send subsequent messages or select subsequent tasks, the receiving action of the proactively reported message is used as the starting point to establish a mirror task unit; otherwise, only the log is saved.

[0269] For fragmented responses, when the chip communication protocol sets a fragment group identifier, new response data (messages) with the same node identifier, session identifier, message type, and fragment group identifier are grouped into the same group. When no fragment group identifier is set, messages belonging to the same incomplete task, with the same node identifier, session identifier, and message type, and consecutive frame sequence numbers from the first fragment to the last fragment, are grouped into the same group. When the protocol sets a byte offset field, the fragments are arranged in ascending order of byte offset; when no byte offset field is set but a fragment sequence number is set, the fragments are arranged in ascending order of fragment sequence number. When both exist simultaneously, the two arrangements are checked for consistency; if they are inconsistent, a position conflict is recorded and reassembly is stopped. Subsequently, missing fragments and duplicate fragments are checked, duplicate protocol headers are removed, and the data portion is concatenated. After all fragments are complete, the response code, running status, link identifier, task identifier, retry sequence number, recovery identifier, and chip return data are extracted from the reassembled complete response. Finally, the task number, original sent message, position and value of fixed sent fields, sent trigger condition, sent time interval, response message attribution condition, complete response judgment condition and response data field are written into the image file to form an image task unit.

[0270] Second, generate a response binding image record and an initial test load image. Specifically, trace the source of fields in subsequent packets to generate a response binding image record and an initial test load image.

[0271] More specifically, for fields in subsequent transmitted data (such as transmitted messages) that are not recorded as fixed transmission fields, the process traces backward from the field's position in the transmission buffer, along write statements, variable assignment statements, and computational expressions. When the application source code is available, all assignment branches related to the field are examined according to the variable's definition, assignment, and usage relationships. When only the compiled executable file or firmware image is available, the field's source is traced backward from the instruction that writes to the transmission buffer, along the register or memory address used by that instruction. When the written value comes from a register or memory address, the corresponding register assignment instruction or the corresponding memory address is searched sequentially forward along the program path that leads to the write instruction. When data copying, byte order adjustment, bitwise operations, truncation, concatenation, or encoding is encountered, the processing method and parameters are recorded, and the input data is traced further. When function calls or conditional jumps are encountered, the return path or branch path that can form the written value is examined. The tracing stops when a fixed value, unrecorded external input, or memory area storing the complete response of the preceding sequence is reached. If the source is a complete preceding response, then the specific response data field is mapped according to the read position and length.

[0272] When a program constant is traced, the target field is added as a fixed sending field; when the response data field of the preceding mirror task unit is traced, the target field is identified as a dynamic field; if the source still cannot be determined, the position, length, and specific reason for not being able to determine the source of the target field are recorded, and the generation of executable records involving that field is stopped. Specific reasons include: the existence of two or more unavoidable assignment sources, the field value coming from unrecorded external input, or the inability to establish a correspondence between the data in the compiled program and the specific response data field.

[0273] The dynamic field reference stores the source task number, the position and length of the source response data field in the reassembled complete response, byte order, encoding method, bitmask, truncation or concatenation rules, and the position and length of the target field. Multi-byte fields are arranged according to the protocol specifications; when bitmasking, truncation, concatenation, or encoding processing is required, the corresponding mask value, start bit, field length, concatenation order, or encoding method is recorded, and the source response data field is converted according to the recorded processing method and parameters during mirroring.

[0274] The system reads the actual bytes of the source response data field from the field communication log, converts them according to the byte order, encoding method, bitmask, and truncation or concatenation rules recorded in the dynamic field reference, and compares the converted byte sequence with the target field of subsequent historical sent messages in the field communication log. If the lengths are the same and all bytes are identical, the dynamic field reference is retained; otherwise, other assignment statements, intermediate variables, and conditional branches at the same send buffer location are checked. The dynamic field is written to the target field location corresponding to the next task's send message template, or to the corresponding location of the send buffer where the message is to be sent. Then, the length field, checksum field, and cyclic redundancy check field are recalculated and updated according to the chip communication protocol. If the chip communication protocol does not set any of these fields, the generation or update process for that field is not performed.

[0275] Next, from the response processing branches set for the current test task in the aforementioned application, branch conditions are extracted based on the response code, key flags, timeout status, and current consecutive retries. The aforementioned application refers to the program responsible for constructing and sending messages, receiving chip responses, and selecting subsequent tasks in the actual business process. The original judgment conditions of the first branch are retained. For each subsequent branch, responses already covered by previous branches are excluded from the responses corresponding to their original judgment conditions, ensuring that each response transition condition is mutually exclusive. If the application has a default branch, the remaining parsable responses are mapped to the default branch; if there is no default branch, undefined response conditions are created to receive responses that can be parsed according to the chip communication protocol but do not meet any explicit branch judgment conditions. Each sequentially processed response transition condition corresponds to a unique next test task number or termination result, and is saved as a response binding mirror record along with the current task number, complete response judgment conditions, dynamic field references to the next task's sent message, and conversion rules. The dynamic field references and field conversion rules for the next test task's sent message include: the source task number, the position and length of the source response data field, the position and length of the target field, and the byte order, encoding, bitmask, and truncation or concatenation method used before the source response data field is written to the target field. The mirror task unit and response binding mirror record are associated with the current task number, and the power-on startup entry task number is saved to form the initial test load mirror.

[0276] Third, the execution path of the initial test load image is checked and the encapsulated test conditions are solidified. Specifically, the availability of the image is checked to form an executable test load image.

[0277] More specifically, the mirror task unit is treated as a node, and the response binding mirror record is treated as a directed edge, expanding layer by layer from the power-on startup entry point. Starting from the power-on startup entry task, a sequence of tasks that have a response binding mirror record between each two adjacent test tasks and can sequentially reach subsequent mirror task units or termination results is defined as a reachable path.

[0278] For response-bound image records that use the current consecutive retries as a response transfer condition and cause the current test task to be executed again when the response transfer condition is met, the retry path formed by the repeated execution of the current test task is expanded by increasing the current consecutive retries from 0 to the retry limit. The retry limit is the maximum consecutive retries set by the application for the current test task; if the maximum number of retries specified by the chip communication protocol is less than the value set by the application, the number of retries specified by the chip communication protocol is used.

[0279] If a task has already occurred and there is no upper limit to the number of attempts, it is determined that an unending loop exists. During traversal, only the mirror task unit, the response-bound mirror record, and the candidate task processing results that the chip communication protocol can actually generate are retained. These candidate task processing results include: complete and parseable response, partial response followed by timeout, no response followed by timeout, protocol format or verification error, unassignable message, response assignment conflict, proactive reporting triggering subsequent tasks, and reaching the retry limit. Among them, complete and parseable response, partial response, and no response are generated by the complete response judgment condition and the response timeout condition; protocol format or verification error is generated by the message parsing rules of the chip communication protocol; unassignable message, response assignment conflict, and proactive reporting triggering subsequent tasks are generated by the response data assignment conditions established above; reaching the retry limit is generated by the retry conditions in the application program or the chip communication protocol.

[0280] Perform a mutual exclusion check on any two response transition conditions under the same test task. The specific comparison is as follows:

[0281] For response codes, first, according to the response code value range specified by the chip communication protocol, convert the equal to, not equal to, value range, or enumerated values ​​in each response transition condition into a set of response codes allowed by that response transition condition. Then, calculate the intersection of the two response code sets. If the intersection is empty, the two conditions cannot be satisfied simultaneously by the same response code; if the intersection is not empty, the response codes in the intersection are those allowed by both conditions. When a response transition condition does not restrict response codes, all response codes allowed by the chip communication protocol are taken as the set of response codes allowed by that response transition condition.

[0282] When two response transition conditions have the same response code, do not have opposite values ​​for the same key flag, do not conflict with each other regarding timeout requirements, and contain at least one identical integer in their respective retry intervals, it indicates that an actual response result can simultaneously satisfy both response transition conditions, and these two response transition conditions are recorded as condition overlap. If any of the above conditions are not met, the two response transition conditions are mutually exclusive.

[0283] For each dynamic field, check its availability in each test reachable path, including: the source task has been executed and formed a complete response before entering the target task; the position and length of the source response data field do not exceed the complete response; the bitmask and truncation range do not exceed the source response data field; all concatenated fields exist and their total length equals the target field length; the number of bytes after encoding equals the target field length; and each response message type that can enter the current condition contains the required fields. When a task with the same number is executed multiple times, the most recent complete response before the target task was sent is referenced by default. When the application saves and calls the response data of an earlier executed task, the dynamic fields are checked according to the complete response actually called by the program, and the most recent complete response is not used as a substitute.

[0284] If any of the above conditions are not met, output the corresponding task number and the location of the unobtainable response data field. The initial test load image must not be used for chip testing.

[0285] After the check is passed, the configured packaging test conditions and their allowable ranges are written into the initial test load image as the basis for test condition verification before chip screening begins. It should be noted that boundary testing only changes voltage, temperature, transmission timing, or communication load, and does not change the response binding relationship. Before the first batch FT, small-batch mass production verification is performed using known qualified chips and samples that can stably reproduce known faults to check the entry task, test vectors, response time limits, branch coverage, and failure determination. The number of task executions after retries on each reachable path is counted, the maximum value is taken as the maximum allowed number of task executions, and the image version number and file checksum are saved to form an executable test load image.

[0286] Fourth, based on the actual response of the chip under test, the executable test load image is executed in a closed loop. Specifically, the chip to be screened (i.e., the chip under test) is loaded, the next task (next test task) is selected based on the actual response, and the next message to be sent is generated driven by the actual response, thereby completing the single chip qualification test. Figure 4 As shown, the chip to be screened (the chip to be tested) returns a response. The response code and response data fields are read from the response. The retry, switch or recovery task corresponding to the response is selected. The session identifier in the response is used to regenerate the next message to be sent. Before sending, the chip is checked. If the check fails, the subsequent path is driven by the actual response. If the check passes, the execution continues along the path corresponding to the actual state of the chip to be screened.

[0287] More specifically, the package batch and chip serial number of the chip under test are written into the test execution record. The chip under test is installed into the adapter socket. The test load board connection, actual voltage, environment and communication interface are checked. The specified version of the executable test load image is loaded. Starting from the power-on startup entry, for each test task executed, the number of the current test task, the number of the previous test task, the start time of the current test task and the completion time of the transmission of the data sent by the current test task are recorded.

[0288] Upon receiving a response, the new response data is assigned to the corresponding unfinished task according to the saved response data attribution conditions; if it is a fragmented response, it is reassembled according to the determined fragmentation grouping, arrangement and connection rules.

[0289] When the message belonging to the current test task meets the complete response judgment condition, the complete response completion time is recorded. The actual response latency of the current test task is obtained by subtracting the message's transmission completion time from the complete response completion time, for subsequent comparison with the upper limit of the current test task's response latency. If a complete response has not been formed after the response timeout period since the transmission completion time, a partial response record or no response record is saved based on the received messages. The response transfer condition with timeout result as the judgment content is searched in the response binding mirror record of the current test task. When a complete response is formed, the response code, key flags, and response data fields are read from the complete response (i.e., the actual response), and the current test task is marked as not having timed out. If a complete response has not been formed after the preset response timeout period, the actual timeout result is recorded, but the response code, key flags, and response data fields, which can only be obtained from the complete response, are not read. In addition, the current consecutive retries can be read from the retry counter corresponding to the current test task.

[0290] The system sequentially checks each response binding mirror record associated with the current test task. When a response transfer condition specifies the response code, critical flags, timeout result, or current consecutive retries, the system compares the actual response result of the current test task with that response transfer condition. Unspecified conditions are not included in the comparison. If only one response binding mirror record satisfies all target response transfer conditions, the next task number is read from that response binding mirror record. If no response binding mirror record satisfies all response transfer conditions, the system stops selecting the next execution node, records the current test task's identifier, complete response or timeout result, unmatched response codes, critical flags, and current consecutive retries, outputs "response processing missing," and enters test invalidation termination. If the response transfer conditions of two or more response binding mirror records are simultaneously satisfied, the system outputs "mirror condition conflict" and enters test invalidation termination.

[0291] For each dynamic field in the transmission message of the next test task, the source task identification information (such as the source task number), the position and length of the source response data field, the target field position, and the field conversion rules are read from the response-bound mirror record. Then, according to the source task identification information, the complete response of the corresponding task is found in the preceding complete responses already generated in the current test of the chip under test. The source response data field is read from the specified position, and byte order adjustment, bitmasking, truncation, splicing, or encoding conversion is performed. The conversion result is written to the target field of the transmission message of the next test task. After all dynamic fields are written, the length field, checksum field, and cyclic redundancy check field in the transmission message of the next test task are regenerated according to the chip communication protocol.

[0292] Before sending data for the next test task, two checks are performed: a next task number check (first check) and a dynamic field padding value check (second check). The next task number check compares the next task number the test program is preparing to execute with the next task number stored in the uniquely matching response binding mirror record. The dynamic field padding value check rereads the actual complete response of the source task, regenerates the expected byte sequence according to the field positions and conversion rules stored in the response binding mirror record, and then compares the expected byte sequence with the actual padding value of the target field in the next test task's sent data. If the actual padding value differs from the expected byte sequence in the number of bytes, or if the number of bytes is the same but any corresponding byte is different, the dynamic field padding value check fails. Only after both checks pass will the next test task's sent data be sent.

[0293] Therefore, the next test task and the next message content are both determined by the actual response of the chip currently under test. For example, a complete network response returns the session identifier of the current chip. When subsequent service messages need to carry this identifier, the test program retrieves the value from the specified field of the current chip's response and writes it into the target field according to the chip's communication protocol, without copying the session identifier of the reference chip.

[0294] When the current task is a communication rate test, the amount of valid service data confirmed by the receiving end and the corresponding transmission duration are statistically analyzed according to the chip communication protocol or test specification of the chip under test, and compared with the lower limit of the communication rate saved in the executable test load image. The test load board provides the actual working electrical load, and the test program executes digital logic, interface communication, exception handling, and boundary condition tasks, thereby combining workload simulation with response-driven path selection.

[0295] When the actual response only matches an undefined response condition, an abnormal chip response is recorded, and the chip fails to terminate. When no response is matched with any bound image record, the response processing is missing. When multiple records are matched simultaneously, the image condition conflict is output. When the next test task number verification fails, or the actual filled value of the dynamic field is inconsistent with the regenerated expected byte sequence, the image execution misalignment is output. When the actual power supply voltage or environmental conditions exceed the range saved in the test load image, the communication interface configuration is inconsistent with the image record, the master node has not completed power-on initialization, the specified master-slave 1:1 connection has not been established, or protocol messages cannot be sent and received normally, the test condition is invalid. When the number of tasks actually executed exceeds the maximum number of task executions written to the test load image, the image execution loop is output. Missing response processing, image condition conflict, image execution misalignment, invalid test conditions, and image execution loop all enter test invalid termination, and the chip is not directly judged as unqualified. Instead, the image is corrected or the conditions are restored, and the test is retested. Each test task saves the entry conditions, start and end times, next task number or termination result, connects them according to time to form the actual task path, and saves the complete response and dynamic field generation records.

[0296] Fifth, complete the individual chip screening and associate it with packaging test data to form a closed loop between packaging test and FT yield. Specifically, associate the packaging test data, calculate the batch FT yield, and if the yield is unqualified, re-perform the individual chip pass inspection; if the yield is qualified, generate the final batch screening record. Figure 5 As shown, the batch screening records are summarized, invalid test results are removed, the number of valid tests is calculated, and the FT yield is calculated. If the FT yield reaches 98%, the final batch screening record is output. If the FT yield does not reach 98%, the reason for the invalid test is corrected or the packaging side is checked, and the affected chips are retested.

[0297] More specifically, first identify and separately save test termination records for the corresponding chips. The test results for these chips are not included in the count of qualified and unqualified chips. After the test load mirroring is corrected or the test conditions are restored, the chip is retested. For chips that pass the test, read the execution results of each task according to the task execution order in the actual task path. If the power-on startup task or firmware flashing subtask is not completed, record a startup failure or flashing failure at the corresponding task location, and cause the actual task path to enter chip failure termination. After power-on startup is completed, continue reading the execution results of the networking task; if networking is not completed, or if received messages cannot be parsed according to the chip communication protocol, record a failure result at the networking task or corresponding communication task location.

[0298] After the current test task generates a complete response, the response code, key flags, timeout status, and current number of consecutive retries are compared with the response transition conditions. If the actual response can only enter an undefined response condition, an abnormal response is recorded; if the current number of consecutive retries reaches the retry limit and a complete response matching a clear response transition condition is still not generated, a retry failure is recorded. The actual response latency of each task is also compared with the corresponding response latency limit, and the communication rate test result is compared with a communication rate limit of 10 Mbps; if the actual response latency exceeds the corresponding limit or the communication rate is lower than the communication rate limit, a performance test failure is recorded at the corresponding task location.

[0299] If, during test execution, the chip is detected to have re-entered power-on, the reset flag changes, or the startup message reappears, an abnormal reset is recorded, and the actual task path terminates due to chip failure. The earliest failure result is retrieved according to the time sequence of the actual task path, and this task is designated as the first failed task. The current valid test result for this chip is recorded as unqualified. If the actual task path completes the tasks specified in the image sequentially and reaches successful termination without any failure results, the current valid test result for this chip is recorded as qualified.

[0300] The screening results of the individual chips are associated with the appearance, size, solder balls, voltage, current, power consumption, basic functions, and necessary reliability check results of the same chip. The first task in the actual task path to encounter a non-conforming condition and its record location is the first failure location. Simultaneously, the execution result, complete response or timeout record, actual response latency, current consecutive retries, source task number and source response data field location referenced by dynamic fields, and the image version used in this test are saved. Duplicate imported records are removed by chip serial number, packaging batch, test time, and image version, retaining the original message bytes, and the task number, termination type, first failure location, and failure mode are converted into a unified code. Qualified chips are written to the good product list and stored on the corresponding disk, while non-qualified chips are written to the isolation list and prohibited from entering the next process, achieving full inspection and individual traceability for each chip.

[0301] Summarize the screening records of individual chips in the same package batch. Let the total number of completed tests be N, and the number of invalid tests be N0, then the number of valid tests Ne is:

[0302] Ne = N - N0;

[0303] Let Np be the number of qualified samples in the effective test. When Ne is greater than 0, the FT yield Y is:

[0304] Y = Np / Ne × 100%;

[0305] When Ne equals 0, yield is not calculated, and the batch is marked as invalid for all tests. When the FT yield is not lower than 98%, a list of good products, a list of defective products, the distribution of the first failed task, and the final screening record are output. When the FT yield is lower than 98% and there are invalid test records, they are handled according to the termination type. If a response is missing, the response transfer conditions and the corresponding next test task or termination result are supplemented based on the existing branches in the application. Correction stops when the application does not have a corresponding branch. When mirror conditions conflict, the simultaneously matching response transfer conditions are re-divided according to the actual judgment order of the application, so that the same actual execution result matches only one response-bound mirror record. When mirror execution is misaligned, the next task number, dynamic field reference, and field conversion rules are checked and corrected. When test conditions are invalid, the specified power supply, environment, communication interface, and master-slave node configuration are restored. When mirror execution is in a loop, the task jump relationship is checked and the retry limit specified by the application or chip communication protocol is written. After processing, the above path and field checks are re-executed to generate a new version of the executable test load image, and the affected chips are retested and the yield is recalculated. If all tests are valid but the yield is still below 98%, the defective chips are statistically analyzed according to the first failed task, the type of abnormal response, the packaging batch, and the test channel. The chip pins or solder balls, power supply network, communication interface, and load board channel used in each first failed task are then queried. When a particular first failed task or abnormal response type occurs frequently within the same packaging batch, the solder ball contacts, package connections, power networks, communication interfaces, load board channels, and the corresponding number of failed chips related to that task are written into a packaging test anomaly list for packaging-side inspection. However, the objects in the list are not directly identified as the cause of failure. After completing the packaging-side inspection or rework, the test load mirror is re-executed using the same judgment criteria. It should be noted that 98% is the batch judgment value used for product packaging testing in this embodiment; other products can be replaced with the threshold specified in their delivery specifications.

[0306] The closed-loop process for packaging testing and Fourier Transform (FT) yield includes batch FT yield calculation, correction of test failure reasons or packaging-side inspection, retesting of affected chips, and recalculation of FT yield. During this closed-loop process, response latency, retry limits, communication rates, or undefined response conditions are not relaxed due to insufficient yield. Each round saves the number of valid tests, the number of qualified tests, the FT yield, the first major failure task, the image version, corrective measures, and retest results until the final batch screening record is formed.

[0307] Based on the above embodiments, the fixed field communication log is converted into a test load image that can identify complete responses, reference the actual response fields of the current chip, select the next test task according to the current response, and self-verify before sending. This enables different chips to execute along the retry, switching, or recovery paths corresponding to their respective real states, thereby maintaining the consistency of messages before and after, and using path-level failure results for single chip screening and packaging batch yield analysis.

[0308] Based on the above embodiments, the dependencies between tasks, responses, and subsequent messages in the field communication log are structured to establish complete response judgment conditions, response transfer conditions, and reference and conversion relationships from preceding response fields to subsequent sending fields, so that the actual response of the chip to be screened can simultaneously determine the next test task and the next data to be sent.

[0309] In addition, before executing the test, further checks are conducted on whether there are any conflicting test conditions, the reachability of the path, and the source of dynamic fields. During the test, the results of task jumps and field filling are verified to avoid test misalignment caused by inconsistencies between the historical path of the benchmark chip and the current chip operating status. This reproduces the abnormal paths that the chip to be screened may actually enter, reduces misjudgments of chip quality, and improves the consistency and traceability of batch screening.

[0310] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0311] Based on the same inventive concept, this application also provides a sensory control chip testing device for implementing the aforementioned sensory control chip testing method. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more sensory control chip testing device embodiments provided below can be found in the limitations of the sensory control chip testing method described above, and will not be repeated here.

[0312] In one exemplary embodiment, such as Figure 6 As shown, a testing device for a sensing and control chip is provided, comprising: a chip testing module 601 and a result determination module 602, wherein:

[0313] The chip testing module 601 is used to test the chip under test based on an executable test load image; during the testing process of the chip under test, the next execution node is determined based on the actual response generated by the chip under test executing the current test task, wherein the next execution node includes the next test task or test termination;

[0314] The result determination module 602 is used to determine the chip test result of the chip under test based on the test execution record of the chip under test.

[0315] Each module in the aforementioned sensor-controlled chip testing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0316] In one exemplary embodiment, a testing system for a sensing and control chip is provided. The system includes a test load board, a computer device, and a testing machine. The test load board is used to connect to the chip under test; the computer device is used to perform the steps of the method described in any of the above embodiments; and the testing machine is communicatively connected to both the test load board and the computer device.

[0317] Furthermore, the sensing and control chip testing system may also include at least one of the following: chip adapter, programmable power supply, communication transceiver interface, and test data storage device.

[0318] The test unit is used to generate digital stimuli, acquire chip outputs, and perform voltage, current, power consumption, timing, and interface tests. The test load board is used to set up power supply, grounding, communication lines, and simulated loads according to the chip pin arrangement, ensuring test signals are transmitted within specified impedance and bandwidth. The chip adapter socket is used to stably connect solder balls to the load board contacts; the chip adapter socket can be installed independently or integrated with the load board. A programmable power supply provides voltage (e.g., 3.3V) and acquires actual voltage and current; a communication transceiver interface connects to the master node or protocol node simulator; a computer device is used to run image generation and execution programs; and a test data storage device is used to save field communication logs, test load images, and chip screening records.

[0319] It should be noted that when the test machine has integrated power supply, communication channels, clock measurement, or data storage functions, the corresponding independent devices can be omitted. Oscilloscopes, logic analyzers, or bit error rate testers are only used to replace the corresponding channels when the FT test machine cannot meet the requirements for delay, signal integrity, or rate measurement; temperature and humidity test chambers are only used for boundary environment testing; automatic loading and unloading mechanisms can be replaced by manual loading; reliability test boards, high and low temperature aging equipment, vibration equipment, and third-party testing platforms are used to supplement reliability verification and are not essential devices in this application embodiment. Independent firmware programmers can also be omitted; when the FT test machine or load board interface can write to the chip's non-volatile memory area and read the programming results, the firmware programming subtask is directly completed by that interface. The test load board is configured with master nodes, terminal loads, and necessary analog loads according to the actual application connection method, enabling the chip to perform power-on startup, firmware programming, networking, service communication, retry, link switching, and recovery tasks. The high-speed lines of the test load board are routed according to the chip interface impedance to reduce reflections caused by discontinuous traces, vias, and branches; the contact resistance, rated current, and insertion / removal life of the adapter sockets meet the requirements for batch FT. The test program saves the input message, expected resolvable range, response timeout, and allowed termination result for each task, and records the actual output and error location, enabling the test steps to be executed automatically and verified. The test program includes environment initialization, task scheduling, message sending and receiving, response reassembly, dynamic field writing, pre-send verification, abnormal termination, log recording, and report generation. The test load board reproduces the physical connection and load state, and the test program reproduces the application's task selection and message construction process, thus forming a simulated FT workload environment.

[0320] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and databases. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media to run. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for testing a sensor-controlled computing chip.

[0321] Those skilled in the art will understand that Figure 7The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0322] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0323] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0324] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0325] 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, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0326] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0327] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for testing a sensor-controlled computing chip, characterized in that, The method includes: Based on the executable test load image, the chip under test is tested; during the test of the chip under test, the next execution node is determined based on the actual response generated by the chip under test executing the current test task, and the next execution node includes the next test task or test termination; Based on the test execution records of the chip under test, the chip test results of the chip under test are determined.

2. The method according to claim 1, characterized in that, The step of determining the next execution node based on the actual response generated by the current test task performed on the chip under test includes: Determine each response binding image record associated with the current test task; each of the response binding image records is used to record the response transfer conditions and the next execution node identification information bound to the current test task, the response transfer conditions are used to indicate the conditions for executing the next execution node, and the next execution node identification information includes the next test task identification information or the identification information indicating test termination; Based on the actual response generated by the current test task executed by the chip under test, and the image records bound to each response, the next execution node is determined.

3. The method according to claim 2, characterized in that, Any of the aforementioned response binding mirror records is also used to record the complete response determination conditions bound to the current test task, wherein the complete response determination conditions are used to determine whether the actual response forms a complete response; The process of determining the next execution node based on the actual response generated by executing the current test task on the chip under test, and the image records bound to each response, includes: Within the target specified time period, if the actual response meets the complete response judgment condition bound to the current test task, the actual response result of the current test task is determined based on the actual response, and at least one target response transfer condition with a complete and parseable response as the judgment content is determined from the response transfer conditions indicated by each response-bound mirror record. If the actual response does not meet the complete response judgment condition bound to the current test task within the target specified time period, the actual response result of the current test task is determined based on the actual timeout result of the task having timed out, and at least one target response transfer condition with timeout result as the judgment content is determined from the response transfer conditions indicated by each response-bound mirror record. Based on the comparison results of the actual response results with each of the target response transfer conditions, and the identification information of each of the next execution nodes, the next execution node is determined; The target specified time period is a time period that starts at the time when the data sent by the current test task is completed and is timed by a preset response timeout duration.

4. The method according to claim 2, characterized in that, Any of the aforementioned response binding mirror records is also used to record dynamic field references bound to the current test task; After determining the next execution node based on the actual response generated by executing the current test task on the chip under test, and the image records bound to each response, the method further includes: When the next execution node is the next test task, the dynamic field is obtained based on the dynamic field reference indicated by the response binding image record that is jointly associated with the current test task and the next test task; the dynamic field is a field that changes dynamically during the test. Based on the dynamic field, the sending data for the next test task is generated.

5. The method according to any one of claims 1 to 4, characterized in that, The actual response is generated based on the response data belonging to the current test task; During the testing process of the chip under test, the method further includes: Upon obtaining new response data, the new response data is compared with the attribution criteria of the response data of each incomplete task in the incomplete task set. If the new response data is successfully matched with the response data of only one incomplete task in the set of incomplete tasks, the new response data will be assigned to the incomplete task that was successfully matched. If the new response data is successfully matched with the response data attribution criteria of at least two incomplete tasks in the set of incomplete tasks, the new response data is determined to be response attribution conflict data. If the new response data fails to match the attribution criteria of the response data of all incomplete tasks in the incomplete task set, the new response data is determined to be unattributable data. Wherein, any of the unfinished tasks are tasks that have sent data but have not formed a complete response, and the current time has not exceeded the specified time period of the unfinished task; the specified time period of the unfinished task is a time period with the completion time of sending the sent data of the unfinished task as the start time and a preset response timeout duration as the time interval; the response data attribution condition of any of the unfinished tasks is used to indicate the conditions under which new response data belongs to the unfinished task.

6. The method according to any one of claims 1 to 4, characterized in that, The executable test load image is generated based on the following method: Based on the field communication logs of the benchmark chip executing a preset business process, multiple mirror task units are generated; the preset business process includes multiple test tasks executed sequentially, and the field communication logs are communication logs with the benchmark chip. Based on the execution data of the preset business process executed by the benchmark chip, a binding image record between each of the test tasks is generated; any one of the binding image records is used to record the binding relationship between two test tasks. Based on the multiple image task units and each of the bound image records, an initial test load image is generated; If the initial test load image passes the inspection, the encapsulation test conditions are written into the initial test load image to generate the executable test load image.

7. A testing device for a sensing and control chip, characterized in that, The device includes: The chip testing module is used to test the chip under test based on an executable test load image; during the testing process of the chip under test, the next execution node is determined based on the actual response generated by the chip under test executing the current test task, wherein the next execution node includes the next test task or test termination; The result determination module is used to determine the chip test result of the chip under test based on the test execution record of the chip under test.

8. A testing system for a sensing and control chip, characterized in that, The system includes: A test load board, which is used to connect to the chip under test; Computer equipment, said computer equipment being used to perform the steps of the method according to any one of claims 1 to 6; The test machine is communicatively connected to both the test load board and the computer device.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images