A trace32-based embedded controller fault field rapid reproduction and variation test method and system

Abstract

The application discloses a kind of based on TRACE32's embedded controller fault scene fast reproduction and variation test method and system, it is related to embedded system debugging and testing technical field, including the following steps: the communication connection between host computer software and debugger and target embedded system is established by debugging interface, breakpoint trigger condition is set and the register and variable set required to be collected are defined, inline instruction is executed by debugger at breakpoint hit moment, register value and variable value are written into log file and target embedded system is recovered to run, simultaneously, corresponding log file identification is generated according to breakpoint type, target identification and time information.This application is based on non-invasive debugging interface, realizes complete state acquisition and high-precision reproduction, locates fault reason quickly through snapshot rollback and variation test, simultaneously, it has the advantage of low-cost deployment and graphical operation, significantly improves embedded system debugging efficiency and accuracy.

Description

Technical Field

[0001] This invention relates to the field of embedded system debugging and testing technology, specifically to a method and system for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32. Background Technology

[0002] With the increasing complexity of embedded controller software in fields such as automotive electronics, industrial control, and aerospace, the number of sporadic faults occurring during system operation (such as memory out-of-bounds errors, data races, stack overflows caused by nested interrupts, and hardware initialization timing anomalies) is growing. These faults are typically highly random and timing-sensitive, heavily dependent on the system's operating state, and difficult to reliably capture and reproduce using conventional methods. Simultaneously, embedded systems have stringent requirements for real-time performance and resource consumption, making the acquisition of complete operational status information without interfering with normal system operation a critical technical challenge. Therefore, how to achieve complete recording, accurate reproduction, and efficient analysis of fault conditions while ensuring system real-time performance has become a crucial problem urgently needing to be solved in the field of embedded system debugging and testing.

[0003] In existing technologies, fault analysis of embedded systems mainly employs software instrumentation logging or debugger-based breakpoint debugging. Software instrumentation requires embedding log collection code into the target program, which not only consumes limited system resources but may also introduce additional timing disturbances, causing changes or even the disappearance of the original fault symptoms. Furthermore, this method can only obtain information from preset variables and cannot comprehensively reflect the CPU registers and underlying hardware states. While breakpoint debugging based on JTAG / SWD debuggers offers some low-level access capabilities, its automation level is low, making it difficult to capture state snapshots and roll back historical states in complex scenarios. It also lacks the ability to conduct systematic mutation testing of key variables to explore fault triggering conditions. Moreover, in multi-core or heterogeneous system environments, existing technologies struggle to achieve high-precision synchronous control and concurrent fault reproduction, resulting in sporadic problems still heavily relying on manual experience for analysis, failing to meet the demands of complex embedded systems for efficient and accurate fault localization.

[0004] The information disclosed in the background section is only intended to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32, so as to solve the problems in the background art mentioned above.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32, comprising the following steps: The communication connection between the host computer software, the debugger, and the target embedded system is established through the debugging interface. The breakpoint trigger conditions are set and the set of registers and variables to be collected is defined. At the moment the breakpoint is hit, the debugger executes the inline instruction, writes the register values ​​and variable values ​​to the log file, and restores the operation of the target embedded system. At the same time, the corresponding log file identifier is generated according to the breakpoint type, target identifier, and time information. Based on the structured data obtained from parsing log files, register values ​​and variable values ​​are obtained. For any structured data record, the operation of the target embedded system is paused and the corresponding register value and variable value are written to complete the restoration of the historical running state. Then, the running process is started to realize the reenactment of the fault process. Based on the restoration of historical operating status, target variables are selected and their value ranges are set. Mutation values ​​are generated according to the preset mutation strategy, written to the target variables one by one, and breakpoint monitoring is triggered. After the set running time, the log file generation is checked. The generation of new log files is determined as a fault trigger and the corresponding mutation values ​​and operating status information are recorded.

[0007] Preferably, a multi-dimensional configuration approach centered around the breakpoint triggering mechanism introduces a combination of various breakpoint types, memory access behavior types, and conditional expressions. The steps are as follows: Construct a set of breakpoints and enter parameter information for at least one breakpoint type, namely function address breakpoint, function name breakpoint (FN), data address access monitoring (DA), and data variable access monitoring (DN). At the same time, assign a unique identifier to each breakpoint and establish a mapping relationship between the trigger source and the breakpoint object. For the Data Address Access Monitoring (DA) / Data Variable Access Monitoring (DN), three memory access behavior types are set: Read, Write, and ReadWrite, and the memory access behavior types are bound to the breakpoint identifiers. Add conditional expressions, combine the expression content with breakpoint trigger parameters, and connect multiple condition items through logical operators to form a multi-condition joint trigger structure; When all triggering conditions are met, the data recording instruction is executed, writing the register names and variable names into the log content one by one in a preset order, while maintaining the consistency of the field arrangement.

[0008] Preferably, in combination with log data organization and identification requirements, the identifiability and traceability of snapshot information are enhanced by using a unified naming structure and classification rules. The steps are as follows: Set a fixed prefix for the log file and create a prefix classification set corresponding to different data collection sources to distinguish normal data collection data from mutation exploration data through the prefix; A breakpoint type encoding is introduced, which maps function address breakpoints, function name breakpoints, and data access breakpoints to different encoded values ​​and embeds them in the file naming field; The target identifier information is concatenated with the timestamp data to generate a complete file name string containing the address or variable name and time information, and then written to the specified storage path. Add a unique identifier prefix to the data generated by the mutation, and group and store it according to the source type to form a hierarchical structure for different types of log files.

[0009] Preferably, in conjunction with the requirement for instantaneous recording of operational status, an inline instruction execution structure and continuous action flow are introduced to ensure the coordination between the data acquisition process and the program execution process. The steps are as follows: Construct a sequence of instructions containing file creation operations, define the file handle number, and specify the log file storage path and creation method; Insert register read expressions and variable read expressions into the instruction sequence, generate the complete write content according to the string concatenation rules, and set the separator format between fields; Embed the write command into the breakpoint trigger action and set the trigger execution flag so that the data write operation is automatically executed when the breakpoint is hit; After the data writing is completed, the run recovery command is executed, and the file handle is closed, forming a complete record process that includes creation, writing, and closing operations.

[0010] Preferably, combining the log data parsing and structure transformation process, and through unified identification rules and data representation methods, the steps are as follows: Read the text content of the log file, split the string according to the preset delimiter, and extract each key-value pair data fragment; Register names are identified using the format R (register name), and variable names are identified using the format V (variable name) to distinguish the source type of register data and variable data. Construct a unified data structure model to map the parsed key-value pairs to the corresponding field positions, while maintaining the consistency of the field order; The trigger source information and time information are written together into a structured record to generate a complete snapshot data entry, which is then stored in a data set for management.

[0011] Preferably, the control logic surrounding the operation state recovery process reconstructs the execution environment by orderly writing register and variable data, ensuring that the historical operation path has replayability. The steps are as follows: The target processor is put into a paused state, and the current execution context is locked to prevent changes in the running state. Write the register values ​​one by one in the order of register numbers, including the program counter and status register, to ensure that the core execution information is restored; Write variable values ​​one by one according to variable address information, update the corresponding positions in memory with target data, and complete the synchronization of runtime environment data. Release the pause control and start the processor to run, allowing the program to continue execution from the resumed state and enter the specified running path.

[0012] Preferably, regarding the consistency control of the register writing and variable writing processes, a complete recovery path is constructed by matching the execution order with the data. The register writing process requires the synchronous updating of the program counter and the status register, and the data overwriting is completed according to the address mapping relationship during the variable writing process. At the same time, the execution entry point and the register state correspondence are kept consistent during the run recovery phase, forming a state connection mechanism for continuous execution paths.

[0013] Preferably, in conjunction with the needs of variable space exploration, multiple data generation methods are introduced to expand the range of test inputs and enhance the coverage of anomaly triggering conditions. The steps are as follows: Define variable names, data types, and value ranges, and build a variable configuration table to store the variable information in a structured manner; According to the random generation rules, discrete values ​​are generated within a set range, and the generation results are written into the variable test sequence; Construct boundary values ​​and overflow values, including minimum value, maximum value and extended values ​​that exceed the range, and add them to the test set; The variable value range is traversed according to a preset step size to gradually generate a continuously changing data sequence for subsequent execution.

[0014] Preferably, by combining automated detection process design with iterative execution and result judgment mechanisms to form a continuous anomaly identification path, the recordability of the fault triggering process is enhanced. The steps are as follows: Restore the preset running state and write the data value generated in the current iteration to the target variable to complete the test input update; The breakpoint monitoring mechanism is activated, the runtime cycle is entered, and the program flow is executed to trigger breakpoint detection; The log file generation status is detected. By determining whether the file has been generated and whether the content exists, breakpoint triggering behavior can be identified. Write the trigger result and the corresponding variable value into the result list, forming a record sequence containing the iteration number and data value.

[0015] A rapid on-site reproduction and variation testing system for embedded controller faults based on TRACE32 includes host computer software, TRACE32 debugger, and target embedded system; The host computer software is used to establish a communication connection between the TRACE32 debugger and the target embedded system through the debugging interface, configure breakpoint trigger conditions, register and variable acquisition targets, log file naming rules and mutation test strategies, parse the acquired log files, generate structured snapshot data of register values ​​and variable values, and display, manage, rollback select, generate mutation values, control iterative injection and record results for the structured snapshot data. The TRACE32 debugger is used to respond to configuration commands from the host computer software to set and manage breakpoints. When a breakpoint is hit, it executes inline instructions to read register and variable values ​​and write them to the log file. Under the control of the host computer software, it pauses the operation of the target embedded system, writes register and variable values, resumes the operation of the target embedded system, and assists in the monitoring of breakpoints during fault reproduction and mutation testing. The target embedded system is used to run the embedded control program to be debugged, and responds to breakpoint triggering, register writing, variable writing, pause and resume operation under the control of the TRACE32 debugger, so that the historical running state can be reconstructed and execution can continue after writing the mutated value, thereby cooperating to complete the fault process replay and abnormal trigger detection.

[0016] The technical effects and advantages provided by the present invention in the above technical solution are as follows: This invention achieves operational status acquisition and control entirely through the chip debugging interface, requiring no code modification to the target program and consuming no computing or storage resources of the target processor. This fundamentally avoids the timing disturbances associated with traditional software instrumentation methods. Furthermore, it can acquire accurate execution status information without disrupting the system's normal operating rhythm, making it particularly suitable for capturing time-sensitive, intermittent abnormal behaviors. Simultaneously, by directly accessing the processor's internal registers and memory variables, complete operational context information can be obtained in a single acquisition. Compared to relying solely on software logs, this provides more comprehensive and accurate fault scene data, laying a solid foundation for subsequent analysis.

[0017] This invention, based on acquiring complete state information, further provides snapshot-based state recovery capabilities, enabling the system to return to any historical running point and re-execute under the same conditions, thereby achieving deterministic reproduction of complex faults. By combining a replay mechanism with external input data, the internal state is kept consistent with the external input, effectively solving the long-standing technical challenge of reliably reproducing sporadic problems. Building upon this, the invention introduces the concept of mutation testing, automating the modification and multi-round execution of key variables. Through systematic exploration of different input combinations, it quickly locates the key conditions triggering anomalies, significantly improving problem localization efficiency and reducing reliance on human experience.

[0018] This invention achieves high-performance debugging capabilities while fully considering practical application costs and ease of use. All functions can be deployed using only common debugger equipment and a general-purpose computing platform, requiring no additional hardware investment or complex software environment configuration, thus lowering the barrier to entry while ensuring functional integrity. Furthermore, complex operation processes are encapsulated through a graphical interface, allowing key operations such as snapshot acquisition, state rollback, and mutation exploration to be completed through intuitive interaction. This reduces operational complexity and improves the user experience, enabling engineers to conduct debugging and analysis work more efficiently, thereby shortening the overall fault location and repair cycle. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of the overall interface of the host computer of the present invention.

[0021] Figure 2 Add a snapshot target dialog box to this invention.

[0022] Figure 3 Add a breakpoint configuration dialog box to this invention.

[0023] Figure 4 A dialog box is added for the target variant of this invention, and the variable name can be imported from the snapshot list.

[0024] Figure 5 This is the monitoring and rollback list for this invention.

[0025] Figure 6 This is a table showing the results of the mutation exploration of this invention, displaying the variable name, mutation value, and fault status. Detailed Implementation

[0026] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that the description of this disclosure will be more complete and fully convey the concept of the exemplary embodiments to those skilled in the art.

[0027] This invention provides, for example Figures 1-6 The following is a method for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32, with the following steps: In the process of debugging embedded controllers, in order to accurately capture the operating status and completely record the fault scene, a non-intrusive snapshot acquisition mechanism based on the debugging interface is adopted. Through breakpoint triggering, key registers and variables are instantaneously acquired without interfering with the real-time operation of the target system. Combined with unified file naming rules and classification management strategies, the fault data is efficiently organized and supported for subsequent analysis.

[0028] Regarding triggering mechanisms, multiple breakpoint configurations are supported to cover runtime monitoring needs at different granularities, including breakpoints based on function addresses, breakpoints based on function symbol names, monitoring based on memory address access, and monitoring based on variable read / write behavior. For data access breakpoints, three memory access types are further provided: read, write, and a combination of read and write, and conditional expressions are allowed to limit the triggering scenario, thereby improving the targeting and effectiveness of data collection. Breakpoints only trigger snapshot recording when the set conditions are met and the breakpoint is hit, avoiding the generation of a large amount of invalid data in the normal program execution path and reducing the storage and analysis burden from the source.

[0029] In terms of data storage and management, a unified and standardized log file naming convention is adopted, embedding breakpoint type, target identifier, and time information into the file name to form a readable and traceable identification structure. For example, a file name is generated by combining a fixed prefix with the breakpoint category code, target address or variable name, and a timestamp accurate to the second, thereby enabling rapid differentiation between different trigger sources. Recorded data generated during automated exploration is further identified with an independent prefix, ensuring clear isolation between manually monitored data and automatically generated data at the storage level, facilitating subsequent analysis.

[0030] Log files are generated using a unified naming format, which can be set to a fixed prefix_breakpoint type code_target identifier_timestamp.log. The fixed prefix distinguishes the data source type; log files generated during normal snapshot collection can use the prefix SP_, while those generated during mutation exploration can use the prefix SP_MUT_. The breakpoint type code identifies the snapshot trigger source: function address breakpoints correspond to code FA, function name breakpoints to code FN, data address access monitoring to code DA, and data variable access monitoring to code DN. The target identifier records the monitored function address, function name, data address, or variable name. The timestamp records the log generation time to differentiate between similar trigger events. Through these file naming rules, log files from different collection sources, trigger types, and target objects can form a clear and distinguishable classification structure at the storage level, thereby improving log file retrieval efficiency, traceability, and the convenience of subsequent parsing and processing.

[0031] During critical data acquisition, relying on the command execution mechanism provided by the debugger, a pre-constructed inline instruction sequence is executed at the moment the breakpoint is triggered. This instruction sequence consists of three consecutive actions: first, a temporary file for recording data is created; second, the names and corresponding values ​​of registers and variables are written to the file according to a predefined format; and finally, the file is closed and the target system's running state is restored. Data writing adopts a single-line concatenation method, combining all acquired items sequentially into a single record, thereby ensuring the compactness of the data structure and parsing efficiency. The entire process is completed at the debug interface layer, without affecting the execution flow of the target processor, maintaining the original runtime sequence characteristics, and ensuring the authenticity and validity of the captured state information.

[0032] The inline instruction execution structure is implemented using a three-stage PRACTICE instruction flow. First, a log file handle is established and a log file is created using a file creation command. An example of this is: `Open #1"path\prefix_type_target_timestamp.log" / Create`, where `#1` is the file handle number, and `path\prefix_type_target_timestamp.log` is the log file storage path and filename. Second, a breakpoint command is used to bind a data write instruction to the target breakpoint, and the write and resume execution are automatically performed when the breakpoint is hit. An example of this is: `Break.Set<address> / CMD"WRITE #1""PC=""Register(PC)""VarName=""Var.VALUE(VarName)" / RESUME`, where `<address>` represents the breakpoint address, and `WRITE`... #1 indicates writing data to the log file corresponding to file handle #1. Register(PC) is used to read the program counter register value, Var.VALUE(VarName) is used to read the target variable value, and / RESUME is used to restore the target system operation after writing is completed. The third step is to release the file handle through the file close command, which can be exemplarily represented as: Close #1. Through the above three-stage instruction flow of creation, writing, and closing, the register and variable values ​​can be automatically collected at the moment the breakpoint is triggered, and the program execution can be resumed immediately after the collection is completed, thereby realizing non-intrusive data recording based on the debugging interface.

[0033] Regarding the data writing format construction process, the host computer is responsible for automatically generating the corresponding instruction content. During generation, the spacing between register and variable names is uniformly controlled. This is achieved by omitting leading spaces in the first item and adding a single space to subsequent items, thus implementing a space-separated data arrangement format. Simultaneously, the equals sign and numerical portion in the key-value pair structure are encapsulated as strings, and quotation marks are processed using specific escape rules to ensure correct recognition by the debug command parser. This strategy guarantees that the log content maintains readability while possessing good machine parsing compatibility.

[0034] In actual execution, the complete instruction flow includes three parts: file creation instruction, breakpoint binding instruction, and file closing instruction. The file creation phase specifies the storage path and file handle; the breakpoint binding phase embeds the data writing instruction into the breakpoint trigger action and automatically resumes program execution after completion; the file closing phase ensures complete data writing and releases resources. Through this continuous flow, status capture and recording can be completed within a very short time window.

[0035] The inline instruction execution structure is implemented using a three-stage PRACTICE command flow. The first step is to establish a log file handle and create the log file using a file creation command, exemplified by the following format: `Open #1"E:\\SnapShot\\SP_FA_0x800DB83E_20260430142407.log" / Create`. Here, `#1` represents the file handle number, used to reference the same log file in subsequent write and close operations; `E:\\SnapShot\\SP_FA_0x800DB83E_20260430142407.log` represents the complete storage path and filename of the log file, where `E:\\SnapShot\\` is the storage path, `SP` is the normal snapshot acquisition prefix, `FA` is the function address breakpoint type code, `0x800DB83E` is the target identifier, `20260430142407` is the timestamp, and `.log` is the log file extension; ` / Create` indicates that the log file is created at the specified path.

[0036] The second step is to bind the write command to the target breakpoint using breakpoint commands, and automatically execute data writing and program recovery when the breakpoint is hit. An example can be shown in the following form: `Break.Set<address> / CMD"WRITE #1""PC=""Register(PC)""VarName=""Var.VALUE(VarName)" / RESUME`. Here, `WRITE #1` indicates writing content to the log file corresponding to file handle #1. Key-value pairs are separated by spaces; no leading space is added before the first key-value pair, and a leading space is added before subsequent key-value pairs to form a continuous single-line record format. The value part corresponding to each key can be enclosed in double quotes to ensure that the log content maintains complete field boundaries during parsing; when the written content needs to contain quotation characters, two consecutive double quotes "" are used for escaping to meet the PRACTICE syntax requirements. Register values ​​can be obtained through register read expressions such as Register(PC), and variable values ​​can be obtained through variable read expressions such as Var.VALUE(VarName), thus writing register information and variable information into the same log record in a unified format; / RESUME indicates that the target system will be automatically restored after the writing is completed.

[0037] The third step is to release the file handle using the file close command, which can be exemplified as: Close #1. Through the above three-stage command flow of creation, writing, and closing, register and variable values ​​can be automatically recorded at the moment a breakpoint is triggered without modifying the target program code, and program execution can be resumed immediately after recording, thus achieving non-intrusive data acquisition based on the debugging interface.

[0038] In the post-processing stage, the generated log files are monitored in real time. Once a change in the file content is detected, the parsing process is triggered. During parsing, the text data undergoes a structured transformation, register data and variable data are distinguished and marked, and a unified data representation format is established. Register data and variable data are distinguished by different identifiers to facilitate accurate matching in subsequent analysis and playback. After parsing, structured snapshot data is generated and added to the data list for display and management.

[0039] Key-value pairs in the log file are recorded and parsed using a unified tag format. Register names are identified using the format R (Register Name), and variable names using the format V (Variable Name). For example, the program counter register can be recorded as R (PC), and the target variable error code can be recorded as V (g_ErrorCode). During parsing, the log line content is first segmented according to a preset delimiter to extract multiple key-value pair data fragments. Then, based on whether the field name contains the R() or V() tag, it is identified as register data or variable data, respectively. The register name or variable name inside the parentheses is then extracted as an object identifier in the structured data model, and the corresponding value is mapped to the target field position. Through the above tagging rules, the log parsing process can accurately distinguish between register information and variable information, thus providing a consistent data foundation for register writes and variable writes in subsequent state recovery.

[0040] Structured data not only contains specific register and variable values ​​but also associates breakpoint triggering sources and timing information, thus constructing a complete fault context. This approach allows for the establishment of clear time-series relationships across multiple runtime moments, enabling engineers to quickly pinpoint state changes before and after an anomaly. Furthermore, the unified data format provides a foundation for subsequent automated analysis, state rollback, and mutation testing.

[0041] In order to accurately reconstruct historical operating states and stably reproduce fault behaviors during the operation of the embedded controller, a reversible state recovery mechanism is constructed by using structured management of runtime snapshot data and debugging interface writing capabilities. This enables the system state at any acquisition time to be accurately restored, thereby providing basic support for the repeated triggering and in-depth analysis of complex faults.

[0042] During state recovery, the target record is first selected based on the generated snapshot data list. The selected record corresponds to the complete runtime context information at a specific moment, including the set of register values ​​and the set of variable values. Control commands are sent to the target processor through the debug interface to put the processor into a paused state, thus providing a stable environment for subsequent state write operations. In the paused state, the processor's internal registers are written item by item according to the data content saved in the snapshot record, while the corresponding variable addresses in memory are restored. The register recovery process uses a register-by-register write method to ensure that critical data such as the program counter, general-purpose registers, and status registers are accurately restored; the variable recovery process writes the target values ​​to the corresponding storage locations through the variable access interface, thereby ensuring that the software runtime environment remains consistent with the historical moment.

[0043] After all register and variable write operations are completed, the target processor's internal operating state has been reconstructed to the snapshot acquisition time. At this point, processor operation can be resumed via control instructions, allowing the program to continue execution from the specified state. Since no additional logic modifications are introduced during the restoration process, and all state data originates from actual runtime acquisition results, the restored execution path closely approximates the historical true execution trajectory, achieving accurate replay of the running behavior. This state-reconstruction-based execution method avoids the problem of inconsistent states that arise from traditional input replay, effectively improving the stability and repeatability of fault reproduction.

[0044] In practical applications, snapshot data typically corresponds to multiple different points in time. By selecting the state at different points in time, the replay starting point can be flexibly controlled. For example, after detecting abnormal behavior, a stable state before the anomaly can be selected as the recovery starting point, and the program can be re-executed from that position to observe the entire process of the anomaly. By continuously adjusting the recovery starting point, the fault occurrence range can be gradually narrowed, helping to locate the key operation or key variable change that triggered the anomaly.

[0045] During the reproduction process, external input data can also be used for coordinated control. Embedded systems typically rely on external communication data to drive their operation, such as CAN bus messages or other communication interface data. By introducing historical external input data and re-entering this data in chronological order after the state is restored, the consistency of the execution path can be further improved. This ensures that the reproduction process remains consistent not only at the internal state level but also at the external input conditions, thereby constructing a complete runtime environment restoration mechanism.

[0046] By combining internal state recovery with external input replay, deterministic execution in complex scenarios can be achieved. That is, under the same initial state and the same input sequence, the program execution result is consistent, thus transforming sporadic problems into repeatable ones. This characteristic is significant for analyzing data races, timing errors, and boundary condition-triggered problems, because these problems often depend on specific combinations of states and inputs, and are difficult to reproduce stably using only a single method.

[0047] During multiple reproduction processes, snapshot data can also serve as a comparative analysis starting point for different experiments. By comparing the differences in execution results under different starting points, key variables or critical paths affecting system behavior can be identified, thereby helping to locate the root cause of the problem. Furthermore, running the system multiple times based on the same snapshot can verify whether the fault is consistently triggered, further assessing the degree of certainty of the problem.

[0048] Furthermore, the snapshot recovery mechanism offers excellent flexibility, supporting both manual and automatic control modes. In manual mode, engineers can select a specific snapshot and trigger the recovery operation for interactive debugging. In automatic mode, it can automatically execute pause, write, and run controls based on preset procedures, enabling batch reproduction of the process. Regardless of the method used, the core principle lies in achieving controllable reconstruction of the system's operational state through standardized data structures and debugging interface capabilities.

[0049] In the process of complex fault analysis of embedded systems, in order to improve the coverage and location efficiency of abnormal triggering conditions, a variable-level mutation mechanism is introduced to systematically disturb key variables in the running state, and combined with the breakpoint monitoring results to realize automated fault exploration, thereby transforming the debugging process that originally relied on manual experience into a repeatable search process.

[0050] During the definition of mutation objects, an interactive interface provides a variable configuration entry point for specifying the set of target variables to be analyzed. Each target variable includes attribute information such as variable name, data type, and value range. The data type is used to limit the representation of variable values ​​and boundary conditions, such as unsigned 8-bit, 16-bit, 32-bit integers, and pointer types. The value range is used to constrain the upper and lower limits of the data generated during the mutation process, giving the mutation behavior a clear exploration boundary. To improve configuration efficiency, the variable list can be extracted from an existing runtime snapshot and automatically populated, thereby avoiding repetitive input, improving operational convenience, and ensuring that the variable source is consistent with the actual runtime environment.

[0051] Regarding the mutation value generation strategy, multiple data generation methods are employed to cover different types of anomaly triggering scenarios. A random strategy generates discretely distributed data within a set range to simulate unpredictable input conditions. A boundary value strategy generates test data around the extreme positions of the variable's value range, including minimum, maximum, and adjacent overflow values, thus focusing on covering critical regions that may cause overflow, truncation, or sign errors. A stepping strategy traverses the entire range with a fixed step size, gradually covering all possible value ranges through equally spaced scans. The boundary value strategy also includes extended testing of data type limits, such as generating values ​​outside the normal range in unsigned 8-bit variables to test the system's processing capabilities under abnormal input conditions. The combined use of multiple strategies allows the variable space to be fully explored from three dimensions: random distribution, boundary sensitivity, and full-range scanning.

[0052] During execution, a cyclical iterative mechanism is constructed around a predetermined set of mutated variables and strategies. Before each iteration, the system's running state is restored using existing snapshot data, ensuring that each round of testing starts from the same point, thereby eliminating the influence of historical operations and guaranteeing the comparability between different mutated inputs. After the state restoration is complete, the mutated values ​​generated in the current iteration are written to the corresponding variable positions, causing a controlled change in the system's operating environment. Subsequently, a breakpoint monitoring mechanism is activated, using pre-configured breakpoint conditions to observe the program execution process.

[0053] During the runtime phase, a fixed time window is set for performing checks. Within this time frame, the system continues running according to the modified variable states. After runtime, the log file generation is checked to determine if any breakpoints have been triggered. When a new log file is detected that is not empty, it indicates that the breakpoint condition has been met during program execution, and this can be considered a valid exception trigger. At this point, the corresponding log content is parsed and converted into structured data records, along with the current variable values, and stored in the results list for subsequent analysis and comparison.

[0054] If no log generation is detected, the process continues to the next iteration until the preset number of iterations is reached or the user actively terminates the operation. This cyclical mechanism continuously searches for potential anomaly trigger points in the variable value space, gradually approaching the actual conditions under which the problem occurs. Throughout the process, each trigger record contains information such as the variable name, specific value, and trigger status, forming a complete sequence of mutation results and providing data support for problem analysis.

[0055] During the exploration process, execution can be terminated at any time, and the current result set can be viewed. By observing the result list, it is possible to identify which combinations of variable values ​​can trigger anomalies, thereby helping to analyze the correlation between variables and system behavior. For multivariate scenarios, the triggering behavior of different variable combinations can be compared to further narrow down the scope of the problem.

[0056] This mechanism employs a cyclical process of variable definition, data generation, state recovery, runtime detection, and result recording to capture systematic disturbances and anomalies in the operating environment. Compared to traditional single-test debugging methods, this approach can automatically execute a large number of test combinations in a shorter time, effectively improving fault location efficiency. Furthermore, since each round of testing is based on the same initial state, consistency between test results is ensured, making the analysis conclusions more reliable.

[0057] In complex embedded debugging environments, to achieve persistent storage and rapid reuse of working scenarios, a unified data structure is used to centrally describe runtime environment parameters, debugging configurations, and testing strategies. This data is then serialized and saved using a structured text format, forming a configuration carrier that can be repeatedly loaded and parsed. This configuration carrier is organized in .json format, describing various parameter information through key-value pairs. This allows different types of data to be expressed within a unified framework, ensuring readability while facilitating automatic parsing and recovery by the program.

[0058] In terms of configuration content organization, the overall data structure consists of multiple logical fields, including debugging tool path information, display format parameters, snapshot collection target set, breakpoint configuration set, mutation test target set, and exploration strategy parameters. Path information is used to locate the debugging tool executable file and related script resources, ensuring consistency in the runtime environment; display format parameters are used to unify the numerical display method, such as hexadecimal or decimal, to ensure consistent data expression between different modules; the snapshot target set describes the register and variable names to be collected in the form of a string array; the breakpoint configuration set adopts an object array structure, with each item containing the breakpoint type, trigger target, memory access type, and trigger condition; the mutation target set describes the variable names, data types, and value ranges involved in the test; and the strategy parameters record the currently selected mutation algorithm type and execution round.

[0059] The overall process achieves persistence and reusability of the debugging environment through a continuous sequence of configuration generation, serialized storage, automatic loading, structure mapping, and environment restoration. Structured data organization enables complex parameter sets to be expressed in a unified format and efficiently transferred between different runtime stages. Simultaneously, parameterized description and function modeling imbue the configuration management process with quantifiable analytical capabilities, thereby improving system consistency and configuration reuse efficiency while ensuring functional integrity.

[0060] In embedded debugging and fault analysis, to improve operational efficiency and data management capabilities, a graphical interface is used to unify the complex debugging configuration, status monitoring, and analysis processes, enabling different functional areas to work collaboratively within the same interactive framework. The interface adopts a modular layout structure, with each area divided according to functional logic. Visual components abstract the underlying debugging capabilities into operable objects, thereby reducing operational complexity and improving the controllability of task execution.

[0061] In the display format and connection configuration area, the ability to switch between multiple numerical representation methods enables unified display and control of register and variable data. Dynamic switching between hexadecimal, decimal, and binary formats is supported, allowing users to quickly adjust the data view according to analysis needs, thus providing a more intuitive understanding of how different data are represented in the underlying execution process. Meanwhile, in terms of connection configuration, the debugger execution path, configuration file path, and startup script path are centrally managed through interface input boxes, providing clear entry points for key parameters of the runtime environment. Connection control operations are triggered by buttons to establish or disconnect communication with debugging tools, allowing explicit control of the debugging session.

[0062] In the snapshot target editing area, registers and variables to be collected are centrally managed using a list-based structure. Each item in the list corresponds to a specific collection target, supporting dynamic addition and deletion operations, allowing users to flexibly adjust the collection scope according to actual analysis needs. Through the configuration of this area, the data items to be recorded during the collection phase can be precisely defined, thereby avoiding the generation of redundant information and ensuring that key data is not missed. The existence of this area gives clear boundaries to data collection, providing a structured input foundation for subsequent analysis.

[0063] In the breakpoint configuration area, different types of breakpoints are managed through a unified configuration interface. It supports four types of breakpoints: function address, function name, data address, and variable access. Trigger targets are defined by input parameters, and breakpoint triggering conditions are controlled by memory access type selection. For more granular control, conditional expressions can be added to limit the triggering logic, ensuring that breakpoints only activate when specific conditions are met. Breakpoint configurations are presented in a list format, and each item can be deleted or modified, enabling dynamic adjustment of the monitoring strategy. This configuration area allows monitoring of key locations and critical data access behaviors within the program execution path, providing a triggering basis for subsequent status acquisition.

[0064] In the monitoring and rollback area, unified management of historical data is achieved through centralized display of runtime snapshots. The interface displays collected snapshot information in list format, with each record including the trigger source and time information, making data from different runtime moments distinguishable. Start and stop monitoring controls allow for the start and stop of breakpoint-driven snapshot collection, ensuring that collection activities align with the actual analysis pace. Regarding the state rollback function, interactive operations trigger historical state restoration, allowing the target system to return to its runtime state at a specified point in time, thus supporting repeated observation of the problem occurrence process. Furthermore, configuration saving and loading functions allow for persistent storage of current environment parameters and subsequent reloading, avoiding repetitive configuration operations. It also supports importing data from external log files and converting it into snapshot records, further expanding the range of data sources.

[0065] In the automated mutation exploration area, systematic testing of the variable space is achieved through centralized configuration of mutation-related parameters. This area includes baseline snapshot selection to specify the initial state of mutation execution; mutation algorithm selection to determine the data generation strategy; and iteration count settings to control the execution scale. In the variable configuration section, the names, data types, and value ranges of the variables participating in the test are listed in tabular form, ensuring a complete definition for each mutation target. During execution, the exploration process can be started or stopped via control buttons, and the execution status of each iteration is displayed in real time in the results table, including iteration number, variable name, mutation value, whether an exception was triggered, and the corresponding snapshot identifier. The table column width supports dynamic adjustment to accommodate different data lengths, thereby improving interface readability.

[0066] The log output area displays the system's operational status and operational feedback in real-time text format. This area records various key events, including connection status changes, the start and end of data collection processes, status recovery execution status, and mutation exploration progress, providing users with immediate feedback during operation. Log information is output in chronological order, forming a continuous record, thus providing a basis for problem tracking and operation backtracking. Through this mechanism, a correspondence can be established between interface operations and the internal execution status of the system, making the entire operation process observable.

[0067] The overall interface design integrates configuration management, data acquisition, status rollback, and automated exploration into a unified interactive platform through a multi-region collaborative approach. Each region is interconnected via data flow; for example, snapshot data originates from the monitoring region, serves as input for mutation exploration, and also forms the basis for rollback operations, thus creating a closed-loop structure. Complex debugging processes are abstracted using a graphical interface, allowing previously fragmented operations to be completed within a single interface, improving overall work efficiency.

[0068] Furthermore, the interface layout follows the principles of clear functional zoning and concise operation paths, enabling users to quickly locate the required functional areas. Through the combination of conventional controls such as lists, tables, and buttons, data display and operation control are unified, making complex operation processes highly understandable. Logical connections between different areas form a unified workflow, ensuring continuity and consistency throughout the entire process from configuration settings to result analysis, thereby providing stable and efficient operational support for embedded system debugging and fault analysis.

[0069] This invention achieves operational status acquisition and control entirely through the chip debugging interface, requiring no code modification to the target program and consuming no computing or storage resources of the target processor. This fundamentally avoids the timing disturbances associated with traditional software instrumentation methods. Furthermore, it can acquire accurate execution status information without disrupting the system's normal operating rhythm, making it particularly suitable for capturing time-sensitive, intermittent abnormal behaviors. Simultaneously, by directly accessing the processor's internal registers and memory variables, complete operational context information can be obtained in a single acquisition. Compared to relying solely on software logs, this provides more comprehensive and accurate fault scene data, laying a solid foundation for subsequent analysis.

[0070] This invention, based on acquiring complete state information, further provides snapshot-based state recovery capabilities, enabling the system to return to any historical running point and re-execute under the same conditions, thereby achieving deterministic reproduction of complex faults. By combining a replay mechanism with external input data, the internal state is kept consistent with the external input, effectively solving the long-standing technical challenge of reliably reproducing sporadic problems. Building upon this, the invention introduces the concept of mutation testing, automating the modification and multi-round execution of key variables. Through systematic exploration of different input combinations, it quickly locates the key conditions triggering anomalies, significantly improving problem localization efficiency and reducing reliance on human experience.

[0071] This invention achieves high-performance debugging capabilities while fully considering practical application costs and ease of use. All functions can be deployed using only common debugger equipment and a general-purpose computing platform, requiring no additional hardware investment or complex software environment configuration, thus lowering the barrier to entry while ensuring functional integrity. Furthermore, complex operation processes are encapsulated through a graphical interface, allowing key operations such as snapshot acquisition, state rollback, and mutation exploration to be completed through intuitive interaction. This reduces operational complexity and improves the user experience, enabling engineers to conduct debugging and analysis work more efficiently, thereby shortening the overall fault location and repair cycle.

[0072] A rapid on-site reproduction and variation testing system for embedded controller faults based on TRACE32 includes host computer software, a TRACE32 debugger, and a target embedded system. The host computer software establishes a communication connection between the host computer software, the debugger, and the target embedded system through the debugging interface. It sets the breakpoint trigger conditions and defines the set of registers and variables to be collected. At the moment the breakpoint is hit, the debugger executes the inline instruction, writes the register and variable values ​​to the log file, and restores the operation of the target embedded system. At the same time, it generates the corresponding log file identifier according to the breakpoint type, target identifier, and time information. The TRACE32 debugger parses structured data of register and variable values ​​from log files. For any structured data record, it pauses the target embedded system and writes the corresponding register and variable values ​​to restore the historical running state. Then, it starts the running process to reenact the fault process. The target embedded system selects target variables and sets their value ranges after completing the historical operation state recovery. It generates mutated values ​​according to the preset mutation strategy, writes them into the target variables one by one, and triggers breakpoint monitoring. After running for a set time, it checks the log file generation status. The generation of new log files is judged as a fault trigger and the corresponding mutated values ​​and operation status information are recorded.

[0073] This invention provides a method for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32. This method is implemented through the aforementioned system for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32. For details on the specific method and process of the system for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32, please refer to the embodiment of the method for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32, which will not be repeated here.

[0074] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

Claims

1. A method for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32, characterized in that, Includes the following steps: The communication connection between the host computer software, the debugger, and the target embedded system is established through the debugging interface. The breakpoint trigger conditions are set and the set of registers and variables to be collected is defined. At the moment the breakpoint is hit, the debugger executes the inline instruction, writes the register values ​​and variable values ​​to the log file, and restores the operation of the target embedded system. At the same time, the corresponding log file identifier is generated according to the breakpoint type, target identifier, and time information. Based on the structured data obtained from parsing log files, register values ​​and variable values ​​are obtained. For any structured data record, the operation of the target embedded system is paused and the corresponding register value and variable value are written to complete the restoration of the historical running state. Then, the running process is started to realize the reenactment of the fault process. Based on the restoration of historical operating status, target variables are selected and their value ranges are set. Mutation values ​​are generated according to the preset mutation strategy, written to the target variables one by one, and breakpoint monitoring is triggered. After the set running time, the log file generation is checked. The generation of new log files is determined as a fault trigger and the corresponding mutation values ​​and operating status information are recorded.

2. The method for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32 according to claim 1, characterized in that, The multi-dimensional configuration of the breakpoint triggering mechanism introduces various combinations of breakpoint types, memory access behavior types, and conditional expressions. The steps are as follows: Construct a set of breakpoints and enter parameter information for at least one breakpoint type, including function address breakpoints, function name breakpoints, data address access monitoring, and data variable access monitoring. At the same time, assign a unique identifier to each breakpoint and establish a mapping relationship between the trigger source and the breakpoint object. For the data address access monitoring / data variable access monitoring, three types of memory access behavior are set: read, write, and read-write, and the memory access behavior type is bound to the breakpoint identifier. Add conditional expressions, combine the expression content with breakpoint trigger parameters, and connect multiple condition items through logical operators to form a multi-condition joint trigger structure; When all triggering conditions are met, the data recording instruction is executed, writing the register names and variable names into the log content one by one in a preset order, while maintaining the consistency of the field arrangement.

3. The method for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32 according to claim 2, characterized in that, To address the needs of log data organization and identification, the identifiability and traceability of snapshot information are enhanced through a unified naming structure and classification rules. The steps are as follows: Set a fixed prefix for the log file and create a prefix classification set corresponding to different data collection sources to distinguish normal data collection data from mutation exploration data through the prefix; A breakpoint type encoding is introduced, which maps function address breakpoints, function name breakpoints, and data access breakpoints to different encoded values ​​and embeds them in the file naming field; The target identifier information is concatenated with the timestamp data to generate a complete file name string containing the address or variable name and time information, and then written to the specified storage path. Add a unique identifier prefix to the data generated by the mutation, and group and store it according to the source type to form a hierarchical structure for different types of log files.

4. The method for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32 according to claim 3, characterized in that, To meet the requirement of instantaneous recording of runtime status, an inline instruction execution structure and continuous action flow are introduced, with the following steps: Construct a sequence of instructions containing file creation operations, define the file handle number, and specify the log file storage path and creation method; Insert register read expressions and variable read expressions into the instruction sequence, generate the complete write content according to the string concatenation rules, and set the separator format between fields; Embed the write command into the breakpoint trigger action and set the trigger execution flag so that the data write operation is automatically executed when the breakpoint is hit; After the data writing is completed, the run recovery command is executed, and the file handle is closed, forming a complete record process that includes creation, writing, and closing operations.

5. The method for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32 according to claim 4, characterized in that, Combining log data parsing and structure transformation processes, and through unified identification rules and data representation methods, the steps are as follows: Read the text content of the log file, split the string according to the preset delimiter, and extract each key-value pair data fragment; Register names are identified using the R form, and variable names are identified using the V form, in order to distinguish the source type of register data and variable data. Construct a unified data structure model to map the parsed key-value pairs to the corresponding field positions, while maintaining the consistency of the field order; The trigger source information and time information are written together into a structured record to generate a complete snapshot data entry, which is then stored in a data set for management.

6. The method for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32 according to claim 5, characterized in that, The control logic surrounding the runtime recovery process reconstructs the execution environment through the orderly writing of register and variable data, as follows: The target processor is put into a paused state, and the current execution context is locked to prevent changes in the running state. Write the register values ​​one by one in the order of register numbers, including the program counter and status register, to ensure that the core execution information is restored; Write variable values ​​one by one according to variable address information, update the corresponding positions in memory with target data, and complete the synchronization of runtime environment data. Release the pause control and start the processor to run, allowing the program to continue execution from the resumed state and enter the specified running path.

7. The method for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32 according to claim 6, characterized in that, To ensure consistency control of register and variable writing processes, a complete recovery path is constructed by matching execution order with data. This requires that the register writing process include synchronous updates of the program counter and status register, and that data overwriting be completed according to address mapping during variable writing. At the same time, the execution entry point and register state correspondence are kept consistent during the runtime recovery phase, forming a state connection mechanism for continuous execution paths.

8. The method for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32 according to claim 6, characterized in that, To address the need for variable space exploration, we introduce multiple data generation methods to expand the range of test inputs and enhance the coverage of anomaly triggering conditions. The steps are as follows: Define variable names, data types, and value ranges, and build a variable configuration table to store the variable information in a structured manner; According to the random generation rules, discrete values ​​are generated within a set range, and the generation results are written into the variable test sequence; Construct boundary values ​​and overflow values, including minimum value, maximum value and extended values ​​that exceed the range, and add them to the test set; The variable value range is traversed according to a preset step size to gradually generate a continuously changing data sequence for subsequent execution.

9. The method for rapid on-site reproduction and variation testing of embedded controller faults based on TRACE32 according to claim 8, characterized in that, By combining the design of an automated detection process, a continuous anomaly identification path is formed through iterative execution and result judgment mechanisms. The steps are as follows: Restore the preset running state and write the data value generated in the current iteration to the target variable to complete the test input update; The breakpoint monitoring mechanism is activated, the runtime cycle is entered, and the program flow is executed to trigger breakpoint detection; The log file generation status is detected. By determining whether the file has been generated and whether the content exists, breakpoint triggering behavior can be identified. Write the trigger result and the corresponding variable value into the result list, forming a record sequence containing the iteration number and data value.

10. A TRACE32-based system for rapid on-site reproduction and variation testing of embedded controller faults, used to implement the TRACE32-based method for rapid on-site reproduction and variation testing of embedded controller faults as described in any one of claims 1-9, characterized in that, This includes the host computer software, the TRACE32 debugger, and the target embedded system; The host computer software is used to establish a communication connection between the TRACE32 debugger and the target embedded system through the debugging interface, configure breakpoint trigger conditions, register and variable acquisition targets, log file naming rules and mutation test strategies, parse the acquired log files, generate structured snapshot data of register values ​​and variable values, and display, manage, rollback select, generate mutation values, control iterative injection and record results for the structured snapshot data. The TRACE32 debugger is used to respond to configuration commands from the host computer software to set and manage breakpoints. When a breakpoint is hit, it executes inline instructions to read register and variable values ​​and write them to the log file. Under the control of the host computer software, it pauses the operation of the target embedded system, writes register and variable values, resumes the operation of the target embedded system, and assists in the monitoring of breakpoints during fault reproduction and mutation testing. The target embedded system is used to run the embedded control program to be debugged, and responds to breakpoint triggering, register writing, variable writing, pause and resume operation under the control of the TRACE32 debugger, so that the historical running state can be reconstructed and execution can continue after writing the mutated value, thereby cooperating to complete the fault process replay and abnormal trigger detection.

Images