Debugging method and system of motion control code based on agent, and storage medium

Abstract

The application relates to the technical field of code debugging, and discloses a debugging method and system for motion control code based on an agent and a storage medium. The agent is connected with development software and obtains relevant permissions. Based on a code rule library, error characters, non-call characters and newly added parameter variables in the motion control code are identified. The characters are marked with annotations, a debugging pointer is inserted for the parameter variables, and a variable chart is visually output. A calculation function is extracted and a total amount of calculation function running is simulated. After sorting, a preset debugging breakpoint is inserted. After being manually activated, the debugging breakpoint is converted into an execution breakpoint, and a full running debugging is performed. The application automatically completes code analysis, marking, breakpoint presetting and data visualization through the agent, simplifies the cumbersome operation of traditional debugging, improves the efficiency and accuracy of motion control code debugging, and adapts to the debugging requirements of a new energy vehicle embedded control chip.

Description

Technical Field

[0001] This application relates to the technical field of code debugging, and in particular to a method, system, and storage medium for debugging motion control code based on intelligent agents. Background Technology

[0002] Driven by the global demand for energy structure optimization, the new energy vehicle industry has achieved rapid development. my country's new energy vehicles have formed a complete industrial chain and technological advantages in core areas such as power batteries, electric drives, and electronic controls, which has placed higher practical demands on the precision and intelligence level of vehicle motion control.

[0003] As the intelligence level of new energy vehicles continues to improve, vehicle posture control is becoming increasingly precise and intelligent. To achieve centralized management and control of vehicle power, steering, braking, and other motion states, new energy vehicles are equipped with a dedicated motion control domain. The core control functions of this motion control domain are implemented based on an embedded control chip. As the nerve center of motion control, the embedded control chip's program code directly determines the stability and accuracy of motion control. This program code needs to be written and compiled using corresponding embedded development software, and logical errors and parameter deviations in the code need to be eliminated through debugging.

[0004] In the software debugging process of embedded control chips, the debugging operation of observing the dynamic parameters of motion control code is quite cumbersome. Existing debugging methods require debuggers to manually set multiple breakpoints or parameter markers in the debugging interface, and multiple clicks are required at each breakpoint to obtain the dynamic parameters during the execution of the motion control code and achieve real-time debugging. The debugging process is redundant and cumbersome, and the debugging efficiency is difficult to meet the actual needs of efficient debugging of motion control code for new energy vehicles. Summary of the Invention

[0005] To improve the debugging efficiency of programs running in embedded control chips, this application provides a debugging method, system, and storage medium for motion control code based on intelligent agents.

[0006] Firstly, this application provides a method for debugging motion control code based on an intelligent agent, employing the following technical solution: A method for debugging motion control code based on intelligent agents includes the following steps: The system establishes a connection between a pre-defined intelligent agent and pre-defined development software, and obtains read, write, and debugging permissions for the development software. Obtain the compilation instructions for the development software, obtain the motion control code based on the compilation instructions, and identify error characters, missing call characters, and newly added parameter variables from the motion control code based on a preset code rule base; Generate character markers corresponding to error characters or missing call characters, and insert the character markers into the motion control code in a preset comment format; The parameter variable is located to obtain its position. A preset debug pointer is inserted at the variable position. The debug pointer points to the storage address of the preset display content. The parameter variable is copied to the storage address and the compilation instructions are executed. The agent draws a variable graph based on the data in the storage address according to a preset display format and outputs it. The calculation function is extracted from the motion control code, the input parameters are identified from the calculation function, the running volume value is simulated based on the input parameters and the preset program simulation library, the function running volume of one execution is simulated based on the calculation process of the calculation function, and the total function running volume is calculated based on the running volume value and the function running volume. Sort the total number of calculation functions in descending order, mark the functions with the highest preset number of calculation functions, and insert preset debugging breakpoints at the marked points; Obtain manual debugging operations, activate corresponding preset debugging breakpoints based on the manual debugging operations, convert the activated preset debugging breakpoints into execution breakpoints, and perform full-run debugging in a loop to traverse all execution breakpoints.

[0007] By adopting the above technical solution, the intelligent agent first analyzes the code to identify useless and erroneous parts; then it automatically sets software marker parameters for variables, and calls the display interface to output the change process during debugging; at the same time, it sorts the data according to the amount of data, sets breakpoint markers at the first number of data points, and can manually activate the breakpoint markers to perform breakpoint debugging.

[0008] Optionally, the step of sorting the total number of function runs in descending order may further include the following sub-steps: Assign the total execution time of the function to the preset intermediate execution time; Obtain the debug start command, and in response to the debug start command, obtain the importance data of the calculation function. Match the corresponding weights according to the importance data as importance weights, and calculate the new function execution total corresponding to the calculation function based on the importance weights and the intermediate execution total. Obtain the debugging end command, and in response to the debugging end command, count the total number of times the breakpoints corresponding to all calculation functions are debugged and the number of times the breakpoints corresponding to a single calculation function are debugged, and calculate the percentage of breakpoints debugged for a single calculation function. The new importance weights of the calculation function are obtained by calculating the proportion of breakpoint debugging and the importance weights.

[0009] By adopting the above technical solution, the total number of function runs is corrected by matching the importance data of the calculated function with the corresponding importance weights. At the same time, after debugging, the importance weights of the calculated function are iteratively optimized and updated based on the proportion of the total number of times the breakpoints are debugged and the number of times each breakpoint is debugged. This achieves dynamic and adaptive adjustment of the sorting of function runs and the setting of debugging breakpoints, making the configuration of debugging breakpoints more in line with the actual importance of the function and the real debugging needs.

[0010] Optionally, the step of the intelligent agent drawing a variable graph based on the data in the storage address according to a preset display format and outputting it further includes the following sub-steps: If the data is a non-Boolean variable, then the time axis is used as the horizontal axis, and the percentage change of the parameter variable is displayed by displaying curves of different colors, with the colors corresponding to the spectrum; The spectrum of the displayed color is positively adjusted according to the total amount of the function operation corresponding to the parameter variable. The larger the total amount of the function operation, the closer the wavelength of the spectrum is to the first light wavelength, and the smaller the total amount of the function operation, the closer the wavelength of the spectrum is to the second light wavelength; the first light wavelength is greater than the second light wavelength. The transparency of the curve is adjusted according to the negative correlation of the importance weights. The greater the importance weight, the lower the transparency, and the smaller the importance weight, the higher the transparency.

[0011] By adopting the above technical solution, the percentage change of non-Boolean parameter variables is visualized with the time axis as the horizontal axis. Combined with the spectral wavelength of the color display of the positive correlation adjustment curve of the total function operation and the transparency of the negative correlation adjustment curve of the important weight, an intuitive visualization of the trend of parameter variable change is achieved. This allows debugging personnel to quickly distinguish the function operation volume and the core importance level through the color depth and curve clarity, thereby improving the identification and readability of debugging data.

[0012] Optionally, the step of the agent drawing a variable graph based on the data in the storage address according to a preset display format and outputting it further includes the following sub-steps: If the data is a Boolean variable, the name of the parameter variable is used as the x-axis, and the total amount of function execution of the parameter variable is displayed by displaying bars of different colors. The bar chart has multiple display bars, and the display color of the display bars corresponds to the spectrum. Calculate the frequency of change of the Boolean variable, and adjust the spectrum of the displayed color according to the positive correlation of the frequency of change. The higher the frequency of change, the closer the wavelength of the spectrum is to the third light wavelength, and the lower the frequency of change, the closer the wavelength of the spectrum is to the fourth light wavelength. The second light wavelength is greater than the third light wavelength, and the third light wavelength is greater than the fourth light wavelength. The height of the display bar corresponds to the total amount of intermediate running; the width of the display bar in the bar chart is adjusted according to the positive correlation of the importance weight. The greater the importance weight, the wider the width, and the smaller the importance weight, the narrower the width.

[0013] By adopting the above technical solution, a multi-dimensional and intuitive visualization of the function's total operation is achieved for Boolean variables using a bar chart with parameter variable names as the horizontal axis and differentiated color bars. The display bar spectral wavelength is adjusted by positively correlated with the variable change frequency, the height of the display bar is matched with the intermediate total operation, and the width of the display bar is adjusted by positively correlated with the important weights. This allows debugging personnel to quickly identify the variable change frequency, operation volume, and core importance level through the color, height, and width of the bar chart. It can accurately identify key Boolean variables with high frequency changes, high operation volume, and high weight without tedious manual screening and analysis, thereby improving the visualization and identification of debugging data and the efficiency of locating core debugging objects.

[0014] Optionally, the method further includes the following steps: The location of the preset debug breakpoint is obtained as the preset location. Based on the preset breakpoint range, the execution breakpoints close to the preset location are searched. If the number of execution breakpoints corresponding to the preset location is greater than the preset reference number, then the preset debug breakpoints corresponding to the preset location will be converted into execution breakpoints.

[0015] By adopting the above technical solution, the preset debugging breakpoints are automatically located, nearby execution breakpoints are searched according to the preset breakpoint range, and the preset debugging breakpoints are intelligently converted into execution breakpoints based on the threshold of the number of execution breakpoints. This achieves automated dynamic optimization and precise layout of debugging breakpoints, eliminating the need for manual searching, judgment and addition of breakpoints, and effectively improving the rationality and adaptability of breakpoint configuration.

[0016] Optionally, the method further includes the following steps: The number of execution breakpoints corresponding to a single debugging session is the execution count. The execution ratio is calculated as the ratio of the number of executions to the preset reference number of executions; or, the execution ratio is calculated as the percentage change in the number of executions. The reference quantity is adjusted based on the positive correlation of the execution ratio.

[0017] By adopting the above technical solution, the execution ratio is obtained by acquiring the number of execution breakpoints in a single debugging session in real time, calculating the ratio of the breakpoints to the preset reference execution quantity or the percentage of their own change, and dynamically adjusting the reference number of breakpoint conversion based on the positive correlation of the execution ratio, thus realizing the adaptive intelligent control of automatically generating the number of execution breakpoints.

[0018] Optionally, the method further includes the following steps: In response to the debug start command, initiate single-step debugging; The number of execution breakpoints is obtained as the breakpoint count. If the breakpoint count is less than the preset breakpoint reference count, single-step debugging is performed cyclically based on the development software; otherwise, single-step debugging is performed based on the preset breakpoint time interval. The breakpoint ratio is calculated as the ratio of the number of breakpoints to the reference number of breakpoints, and the breakpoint time interval is adjusted based on the negative correlation of the breakpoint ratio; or, the non-execution ratio is calculated as the ratio of the number of unexecuted breakpoints to the reference number of breakpoints, and the breakpoint time interval is adjusted based on the positive correlation of the non-execution ratio.

[0019] By adopting the above technical solution, single-step debugging is automatically started in response to the debugging start command. The cyclic single-step debugging or timed single-step debugging mode is intelligently switched according to the number of execution breakpoints and preset reference values. The breakpoint time interval is dynamically and adaptively adjusted based on the breakpoint ratio and the non-execution ratio, so as to realize the automated and intelligent control of the debugging speed and running rhythm of the embedded chip program.

[0020] Optionally, the method further includes the following steps: If the number of breakpoints exceeds the preset maximum breakpoint value, a preset indicator code is inserted at the position of the execution breakpoint in the motion control code. The indicator code is used to output debug indicator markers; all execution breakpoints are converted into preset debug breakpoints. The development software is used to perform full-run debugging, and the output debugging indicator marks are inserted into the corresponding data positions in the variable chart.

[0021] By adopting the above technical solution, when the number of execution breakpoints exceeds the preset maximum value, the system automatically inserts indicator code to output debugging indicator markers and converts the execution breakpoints into preset debugging breakpoints. Through full-run debugging, the debugging indicator markers are accurately marked on the corresponding data positions in the variable chart. This effectively avoids the debugging process from being stuck and cumbersome due to too many breakpoints, and allows for intuitive location of the data nodes corresponding to the breakpoints in the visualization chart, thereby improving the smoothness of debugging and the efficiency of data tracing in scenarios with a large number of breakpoints.

[0022] Secondly, this application provides a debugging system for motion control code based on intelligent agents, employing the following technical solution: A debugging system for agent-based motion control code includes a processor that executes the steps of the agent-based motion control code debugging method as described in any one of the preceding claims.

[0023] Thirdly, this application provides a storage medium, which adopts the following technical solution: A storage medium storing a program, which, when executed by a processor, implements the steps of the debugging method for agent-based motion control code as described above.

[0024] In summary, this application includes at least one of the following beneficial technical effects: it automates the entire process of motion control code debugging through intelligent agents, and combines dynamic iterative optimization of important weights, multi-dimensional visualization of non-Boolean and Boolean variables, intelligent layout and adaptive quantity control of debugging breakpoints, intelligent adjustment of debugging rhythm, and optimization of large-batch breakpoint scenarios. This effectively solves the problems of cumbersome operation, unreasonable breakpoint settings, and unintuitive data observation in traditional embedded motion control code debugging, and improves the debugging efficiency, accuracy, and intelligence level of motion control code for embedded control chips in new energy vehicles. Attached Figure Description

[0025] Figure 1 This is a step-by-step diagram of a method for debugging motion control code based on an intelligent agent.

[0026] Figure 2 It is a sub-step diagram that sorts the total number of executions of the computation function from largest to smallest.

[0027] Figure 3 It is a sub-step diagram that the agent draws a variable graph according to the data in the storage address and outputs it in a preset display format. Detailed Implementation

[0028] The embodiments of this application are described in detail below, and examples of the embodiments are shown in the accompanying drawings.

[0029] In the description of this specification, the references to "certain embodiments," "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples" refer to specific features, structures, materials, or characteristics described in connection with the described embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0030] This application discloses a method for debugging motion control code based on an intelligent agent, adapted to the IAR Embedded Workbench (hereinafter referred to as IAR software) development environment. It is mainly applied to automated debugging scenarios of motion control code in embedded devices such as automotive MCUs and industrial servo drives, solving the technical problems of low efficiency, difficulty in code error detection, cumbersome breakpoint setting, and poor variable data visualization in the traditional IAR environment. In this embodiment, the intelligent agent is a software agent equipped with an automation control engine, integrating the official IAR software API interface library, code syntax detection engine, and data visualization module. The preset code rule library includes IAR compiler syntax specifications, motion control code redundant character judgment rules, variable definition standards, and function format requirements. The preset program simulation library has built-in simulation models of typical motion control working conditions for calculating function running parameters. (Refer to...) Figure 1 The specific steps are as follows: Step S101: The agent establishes a communication connection with the IAR software and obtains debugging permissions. The intelligent agent establishes a two-way communication connection with the locally running IAR development software through the IARC-SPY automation API interface to complete identity verification and permission request: 1. Automatically obtain read and write permissions for the IAR software project, supporting reading motion control source code within the project, modifying code comments, and inserting debugging instructions; 2. Apply for and obtain debugging control permissions for the IAR software to automate the control of the online debugging, compile, and run buttons on the IAR software interface, replacing manual clicking operations; 3. Establish a debugging data transmission channel for bidirectional interaction of subsequent variable data and breakpoint information. After obtaining permissions, the agent enters a standby state and listens for operation commands from the IAR software in real time.

[0031] Step S102: Listen for compilation instructions and identify code exceptions and parameter variables. The agent monitors IAR software compilation trigger signals in real time, including manual clicks of the compile button, shortcut key compilation, and automated compilation instructions. When a compilation instruction is captured, the following operations are performed: 1. Automatically retrieve the motion control source code to be debugged from the project directory of the IAR software; 2. Call the preset code rule library to perform a full scan and inspection of the source code: Identify error characters: including syntax characters that the IAR compiler cannot recognize, numeric out-of-bounds characters, and format error identifiers; Identify characters that have not been called: including obsolete variables that have not been called by any function, redundant code segments, and invalid comment characters; Accurately identify newly added parameter variables: including core control variables such as speed, position, torque, and current in motion control, and distinguish variable storage type and memory address.

[0032] Step S103: Generate character tags and insert code comments in a preset format. For the error characters and missing call characters identified in step S102, the agent automatically generates standardized character tags, which include the exception type, line number, and cause of the problem. Using an IAR compiler-compatible comment format, the character tags are inserted into the corresponding positions in the code. 1. The default comment format is: / / [Agent Tag] Type: XXX|Line Number: XXX|Description: XXX; 2. Example of an error character marker: / / [Agent marker] Type: Syntax error | Line number: 86 | Description: Illegal variable identifier format; 3. Example of a marker with no function call: / / [Agent marker] Type: Redundant variable | Line number: 122 | Description: Not called by any function; The inserted comments can be recognized by IAR software without affecting the code compilation logic, and at the same time, they make it easier for developers to quickly locate code problems.

[0033] Step S104: Locate variables, insert debug pointers, and trigger compilation instructions. 1. Variable location: The agent accurately locates the newly added parameter variable according to the variable addressing rules in the code rule base, and obtains the line number, memory offset address and storage range of the variable in the source code; 2. Insert debug pointer: Insert a preset software debug pointer below the line of code defining the variable. This pointer points to a dedicated storage address for display content in IAR software debug mode. The instruction logic is to automatically copy the real-time data of the variable to this storage address. 3. Trigger compilation: After the debug pointer is inserted, the agent automatically controls the compile button of the IAR software through the API interface to execute the compilation instructions, complete the code compilation and linking, and generate a debuggable firmware program.

[0034] Step S105: Read the storage address data and draw a variable visualization chart. After successful compilation, the agent enters the data acquisition phase: 1. Read variable data from the IAR software debug storage address in real time, including the real-time value, trend of change, and data type of the variable; 2. Based on the preset display format, plot the variable data into a visual chart and output it to a separate display interface: Numerical variables are displayed using time-series curve charts, with the horizontal axis representing the debugging time and the vertical axis representing the variable values; State-type variables are displayed using bar charts to visually represent changes in the variable's state. The charts support real-time refresh, data zooming, and historical data playback, replacing the native variable viewing window of the IAR software and improving data readability.

[0035] Step S106: Extract the calculation function and calculate the total number of function runs. The intelligent agent performs function parsing on the compiled motion control code and completes the calculation of runtime parameters: 1. Automatically extract all core motion control calculation functions from the code, including speed adjustment functions, position closed-loop functions, current calculation functions, etc. 2. Identify the input parameters for each function, such as target speed, feedback position, rated current, etc. 3. Call the preset program simulation library and combine it with the motion control working condition simulation model: The simulation calculates the total volume of the function's execution, that is, the total amount of parameters output during the entire function's execution cycle; Simulate the computational workload of a single function execution, that is, the computational increment for each execution of the function; 4. Calculate the final total function execution volume using a weighted summation formula: Total function execution volume = Execution volume + Execution volume per session × Number of executions. This quantifies the function's workload and core nature.

[0036] Step S107: Sort functions, display labels, and set preset debug breakpoints. 1. Function sorting: The agent sorts all computational functions in descending order of total execution time. The higher the total execution time, the more critical the function is in motion control. 2. Display Labels: Select the top 20% of core functions in the sorted list and add visual label comments to the beginning line of the function code. The label format is / / [Core Debugging Function] Total Runs: XXX. The IAR software interface can display this visually. 3. Preset breakpoints: Insert IAR-compatible preset debug breakpoints at key locations in the marked core functions (function entry, parameter assignment, logical judgment). These breakpoints are software placeholders and will not trigger hardware debug interrupts for the time being.

[0037] Step S108: Respond to manual operation to activate breakpoints and execute full runtime debugging. 1. The intelligent agent monitors the manual debugging operations of the IAR software in real time, including interactive commands such as manually clicking preset breakpoints and selecting breakpoint activation options; 2. Upon receiving a manual activation command, the preset debug breakpoints are converted into execution breakpoints recognizable by the IARC-SPY debug mode in batches and written to the debug controller; 3. The intelligent agent control IAR software starts in full-run debugging mode, executes the motion control firmware program in a loop, and automatically traverses all activated execution breakpoints; 4. The program automatically pauses when it reaches a breakpoint and updates the variable visualization chart data synchronously. Developers can intuitively view the variable status and code execution logic at the breakpoint and complete debugging and analysis.

[0038] Reference Figure 2 The optional sub-step is the one in step S107 that sorts the total number of function runs in descending order: Sub-step S1071: Assigning intermediate total values After calculating the total running amount of the functions in step S106, the agent immediately assigns the initial total running amount of each function (i.e., the quantization result before correction) to a preset intermediate total running amount variable, named temp_run_total, and stores it in the temporary cache of the IAR project. The core purpose of this assignment operation is to preserve the original total running amount data, avoid overwriting the baseline value during subsequent weight correction, and provide a traceable original basis for weight iterative optimization. For example: If the initial total running value of the torque adjustment function is 8500, then temp_run_total = 8500; If the initial total running power of the air conditioner auxiliary power function is 9200, then temp_run_total=9200; If the initial total running value of the brake pressure regulation function is 7800, then temp_run_total = 7800.

[0039] Sub-step S1072: Important weight matching and calculation of total execution time of the new function 1. Debugging Start Command Response to Importance Data Acquisition: The agent listens for debugging start commands in real time via the IAR software's C-SPY debugging interface, including manual clicking of the IAR's Start Debugging button and start signals triggered by automated debugging scripts. Once a command is captured, the agent immediately extracts the importance data for each computational function from a pre-defined function importance level library. This importance data is based on the preset functional attributes of the motion control functions and specifically includes: The category to which a function belongs: for example, the brake pressure regulation function belongs to the core safety category, the torque regulation function belongs to the critical control category, and the air conditioning auxiliary power function belongs to the auxiliary function category. System dependency ratio: core security dependency ratio ≥ 85%, critical control dependency ratio 70%-84%, auxiliary function dependency ratio ≤ 69%; The impact level of the fault is as follows: "fatal" for core safety faults, "serious" for critical control faults, and "minor" for auxiliary function faults.

[0040] 2. Precise Matching of Important Weights: Based on importance data and preset weight mapping rules, the agent matches a unique important weight to each calculation function. The weight mapping rules are adapted to the IAR debugging resource allocation logic, as shown in the table below: Example: Braking pressure regulation function (core safety category, dependency 90%) is matched with an important weight of 1.6; torque regulation function (key control category, dependency 78%) is matched with an important weight of 1.3; air conditioning auxiliary power function (auxiliary function category, dependency 65%) is matched with an important weight of 0.9.

[0041] 3. Calculation of the total amount of new function operation: The weighted product formula is used to calculate the total amount of the new function operation after correction, ensuring that the total amount of operation is strongly linked to the importance. The formula is: Total amount of new function operation = Total amount of intermediate operation × Importance weight; Combined with the previous examples, the following calculations are performed: Braking pressure adjustment function: 7800 × 1.6 = 12480; Torque adjustment function: 8500 × 1.3 = 11050; Air conditioning auxiliary power function: 9200 × 0.9 = 8280.

[0042] The corrected function order is: Braking pressure adjustment function (12480) > Torque adjustment function (11050) > Air conditioning auxiliary power function (8280), which moves the core safety functions forward and ensures that breakpoints are prioritized for functions of high importance.

[0043] Sub-step S1073: Breakpoint debugging percentage statistics 1. Debugging end command response: The agent listens for debugging end signals through the IAR debugging status monitoring interface, including the completion of all execution breakpoint traversal, manual clicking of the StopDebugging button in IAR, and debugging timeout trigger. After the response, the debugging data statistics process is started immediately to avoid the loss of debugging log data.

[0044] 2. Precise statistics on the number of debugging attempts: Extract all breakpoint trigger data for the current debugging session using IAR's DebugLogAPI, and filter and statistically analyze two key metrics: The total number of times all breakpoints in the calculation functions are debugged is denoted as total_debug_count: that is, the total number of times all preset debug breakpoints are activated and triggered in this debugging, for example, breakpoints were triggered 150 times in this debugging. The number of times a breakpoint is debugged for a single calculation function is denoted as single_debug_count: that is, the cumulative number of times the execution breakpoint corresponding to a single calculation function is triggered. For example, the brake pressure adjustment function is triggered 30 times, the torque adjustment function is triggered 25 times, and the air conditioning auxiliary power function is triggered 10 times.

[0045] 3. Breakpoint debugging percentage calculation: The percentage formula is used to quantify the debugging attention of a single function. The formula is: Breakpoint debugging percentage = (Number of debugging times for a single calculation function ÷ Total number of debugging times for all calculation functions) × 100%; Calculated with examples: Brake pressure adjustment function: 30 ÷ 150 × 100% = 20%; Torque adjustment function: 25 ÷ 150 × 100% ≈ 16.67%; Air conditioning auxiliary power function: 10 ÷ 150 × 100% ≈ 6.67%.

[0046] Sub-step S1074: Iterative optimization of important weights The agent uses a dynamic iterative formula to update the important weights of the calculation function, so as to continuously adapt the weights to the actual debugging needs. The iterative formula is: new important weight = original important weight × (1 + breakpoint debugging ratio). Formula design logic: The higher the proportion of breakpoint debugging, the more attention the function receives in actual debugging, and its true importance is higher than the initial setting. The weight is increased through weighted iteration; conversely, it is maintained or slightly adjusted to ensure the rationality and smoothness of weight iteration.

[0047] Calculate the new significance weights based on the previous example: Braking pressure adjustment function (original weight 1.6): 1.6 × (1 + 20%) = 1.92; Torque adjustment function (original weight 1.3): 1.3 × (1 + 16.67%) ≈ 1.52; Air conditioning auxiliary power function (original weight 0.9): 0.9 × (1 + 6.67%) ≈ 0.96.

[0048] The updated weights will be stored in real time in the function importance level library, overwriting the original initial weights, and synchronized to the breakpoint configuration association data in IAR, serving as the benchmark weights for calculating the total number of new function runs during the next debugging session.

[0049] In addition, the exception handling mechanism is as follows: 1. If the importance data of a certain calculation function is missing, such as a custom newly added function not being entered into the level library, the agent will automatically assign it a default importance weight of 1.0, a key control class lower limit value, and mark the importance data to be supplemented in the IAR project log to avoid process interruption; 2. If the debugging count fails, such as due to corrupted IAR debugging logs, the agent retains its original weights, does not perform iterative updates, and triggers a log repair command to ensure that the debugging data can be counted normally in the next iteration.

[0050] Reference Figure 3 The optional sub-step is the one in step S105 where the agent draws a variable graph based on the data in the storage address according to a preset display format and outputs it. Sub-step S1051: Non-Boolean variable judgment and basic chart construction After the agent reads the parameter variable data from the storage address through the IAR debug data interface, it first performs data type filtering: 1. Variable type identification: By judging the storage format of variables (such as whether it is int, float, double type) and the range of values ​​(whether it contains consecutive numbers rather than just 0 / 1), non-Boolean variables are filtered out, and logical variables are excluded from interference; 2. Basic Chart Framework Setup: Construct time-series visualization charts adapted for motion control debugging. Specific configurations are as follows: The horizontal axis is based on the debugging time axis. The time unit is adaptively switched according to the IAR debugging mode. Short-term fine debugging is set to millisecond level, and long-term working condition debugging is set to second level. The horizontal axis range automatically covers the full duration of a single debugging session, from the start of IAR debugging to the completion of all breakpoint traversal, and marks key time nodes, such as breakpoint trigger time. The vertical axis is measured by the percentage change of the parameter variable. The percentage change is calculated using a standardized formula to ensure that the change trends of variables of different magnitudes can be compared horizontally. The formula is: Percentage change = [(Real-time value of variable - Initial value of variable) / Initial value of variable] × 100%; where the initial value of the variable is the first sampled value captured after IAR starts debugging, and the real-time value is the variable data acquired by the agent at a preset sampling frequency (10ms / time in this embodiment, synchronized with the debugging data refresh frequency of IAR); Initial display configuration: Assign an independent curve to each non-Boolean variable, set the initial color to the default blue light (450nm wavelength), and set the initial transparency to 0.5 to ensure clear basic visualization without overlapping or occlusion.

[0051] Sub-step S1052: Spectral color adjustment based on total function execution volume 1. Accurate acquisition of total running volume: The agent extracts the total running volume of the new function of the calculation function to which the current non-Boolean variable belongs, that is, the quantization result after weight correction in step S1072. For example, the total running volume of the torque adjustment function to which the motor torque variable belongs is 11050. This data is read from the temporary cache area of ​​the IAR project to ensure that it is consistent with the data source of function sorting and breakpoint setting. 2. Wavelength Mapping Matching: The spectral mapping rule library is invoked. Following the positive correlation logic that the larger the total amount of function execution, the closer the wavelength is to the first light wavelength (650nm), segmented mapping is performed. The specific mapping relationship is shown in the table below, ensuring significant color differences in variables across different total execution ranges. Example: The new total operating value of the function to which the braking pressure variable belongs is 12480, falling into the range (9000, +∞), corresponding to a wavelength of 650nm, and the curve color is automatically adjusted to red; the new total operating value of the function to which the air conditioning auxiliary power variable belongs is 8280, falling into the range (7000, 9000], corresponding to a wavelength of 600nm, and the curve color is adjusted to yellow. 3. Real-time color synchronization: The agent synchronizes the adjusted color parameters to the chart interface through the IAR visualization interface. If the total amount of function execution changes due to weight iteration (step S1074) during subsequent debugging, the curve color will be automatically remapped to ensure that the visual features match the core attributes of the variables in real time without the need for manual updates.

[0052] Sub-step S1053: Adjusting curve transparency based on importance weights 1. Important weight acquisition: Extract the important weight of the calculation function to which the current non-Boolean variable belongs. The initial weight comes from the function importance level library, and the weight after iteration comes from the optimization result of step S1074. For example, the important weight of the function to which the braking pressure variable belongs is 1.92. 2. Target Transparency Calculation: Transparency is calculated using the negative correlation function of the transparency adjustment model to ensure that the higher the importance weight, the less transparent the curve (the more visually prominent). The function formula is: Target Transparency = 0.9 - (Importance Weight - Minimum Weight) × (0.9 - 0.2) / (Maximum Weight - Minimum Weight); where the minimum weight is the lowest preset value (0.5) in the function importance level library, and the maximum weight is the highest preset value (1.8). This formula ensures that the transparency is linearly adjusted within the range of 0.2-0.9, avoiding visual failure caused by extreme values.

[0053] Example calculation: The important weight of the function to which the braking pressure variable belongs is 1.92 (if it exceeds the maximum weight, it is calculated as 1.8): Target transparency = 0.9 - (1.8 - 0.5) × 0.7 / (1.8 - 0.5) = 0.2 (least transparent, most visually prominent); The important weight of the function to which the torque variable belongs is 1.52: Target transparency = 0.9 - (1.52 - 0.5) × 0.7 / 1.3 ≈ 0.9 - 0.54 = 0.36 (relatively opaque, visually clear); The function to which the air conditioner auxiliary power variable belongs has an important weight of 0.96: Target transparency = 0.9 - (0.96 - 0.5) × 0.7 / 1.3 ≈ 0.9 - 0.25 = 0.65 (relatively transparent, visually weakened); 3. Transparency Activation and Layered Display: The intelligent agent applies the calculated target transparency to the corresponding variable curves, achieving a layered effect in the IAR visualization interface where "high-weight variable curves are displayed in front, and low-weight variable curves are displayed transparently behind." When multiple variables are superimposed, the curves of core safety variables (high weight + red light) are automatically placed in the visual focus, while the curves of auxiliary function variables (low weight + blue light + high transparency) do not obscure the core information, achieving intelligent layered visualization without manual selection.

[0054] In addition, the exception handling and adaptation mechanisms are as follows: 1. If the total number of functions or important weight data of a non-Boolean variable is missing, such as when a new function has not completed weight matching, the agent will automatically assign a default value to it. The total number of functions is 3000 by default, the weight is 1.0 by default, the curve color is set to cyan and the transparency is set to 0.5 to ensure the integrity of the chart. 2. Adapt to the differences in visualization modules across different versions of IAR. The agent automatically detects the IAR version via the API interface and adjusts the color space (RGB / HSV) and transparency parameter formats to ensure normal display in mainstream versions such as IAR Embedded Workbench V8 / V9.

[0055] This optional sub-step is the sub-step in step S105 where the agent draws a variable graph based on the data in the storage address according to a preset display format and outputs it: Sub-step S1054: Boolean variable judgment and basic bar chart construction After the agent obtains the parameter variable data from the storage address through IAR's debug data reading interface, it first completes variable selection and basic chart construction: 1. Accurate identification of Boolean variables: By judging the storage type of variables (whether it is a bool type supported by IAR) and the value range (whether it only contains 0 / 1 binary logical values), Boolean variables are filtered out to eliminate interference from numerical variables; at the same time, metadata such as the name, function, and memory address of each variable are extracted for chart annotation; 2. Basic Bar Chart Framework Configuration: Build a bar chart adapted for IAR debugging scenarios. Specific parameters are as follows: Horizontal axis: The horizontal axis uses the Boolean variable names, which are arranged in the order they are defined in the IAR project. The horizontal axis labels are tilted at 45°, and the spacing between adjacent labels is set to 30px to prevent name overlap. The length of the horizontal axis expands adaptively according to the number of variables to ensure that all variables are displayed completely. The vertical axis is set to the total intermediate execution volume of the function. The range of the vertical axis is set to 1.2 times the maximum value of the total intermediate execution volume of all Boolean variables. For example, if the maximum intermediate execution volume is 9200, the range of the vertical axis is set to 0-11040. The scale interval is set to 1000. The scale labels indicate the specific values ​​for easy reading. Basic column configuration: Assign an independent display column to each Boolean variable, set the initial color to the default dark purple light (390nm), the initial width to 20px, and the basic height = total intermediate running volume ÷ height mapping ratio. For example, if the total intermediate running volume is 7800, then the basic height is 7800 ÷ 10 = 780px. Set the spacing between columns to 15px to avoid visual crowding.

[0056] Sub-step S1055: Adjusting the color of the display bar based on the changing frequency 1. Precise Calculation of Change Frequency: The agent extracts all state data of Boolean variables during the current debugging period through the IAR debugging log interface, and counts the cumulative number of state transitions from 0 to 1 or 1 to 0, i.e., the total number of state transitions. Combined with the total duration of a single debugging session, the change frequency is calculated using the formula: Change Frequency (Hz) = Total Number of State Transitions ÷ Total Duration of a Single Debugging Session (s); where the total duration of a single debugging session is the cumulative time from the start to the end of IAR debugging. Example: If the brake trigger flag changes state 36 times in 180 seconds of debugging, then the change frequency = 36 ÷ 180 = 0.2Hz; if the fault alarm flag changes state 90 times, then the change frequency = 90 ÷ 180 = 0.5Hz.

[0057] 2. Spectral Wavelength Mapping Matching: A Boolean variable feature mapping library is used to perform segmented mapping based on the positive correlation logic that the higher the frequency of change, the closer the wavelength is to the third light wavelength (420nm). The specific mapping relationship is shown in the table below, ensuring that color differences in different frequency ranges are significantly distinguishable. Example: The fault alarm indicator changes frequency of 0.5Hz, falling within the range of (0.2, 0.5], corresponding to a wavelength of 415nm, and the display bar color is adjusted to light purple light; the charging status indicator changes frequency of 0.05Hz, corresponding to a wavelength of 390nm, and remains dark purple light.

[0058] 3. Dynamic color update mechanism: If the operating conditions change during the debugging process, causing the frequency of variable changes to fluctuate in real time, such as the frequent switching of the motor start enable signal under rapid acceleration conditions, the agent will reread the status data and calculate the change frequency through the IAR interface every 500ms, and update the display column color synchronously to ensure that the color matches the variable activity in real time.

[0059] Sub-step S1056: Adjusting bar graph parameters based on intermediate running total and important weights 1. Precise Matching of Display Column Height: The agent extracts the intermediate total execution value of the calculation function to which the Boolean variable belongs, specifically from the temporary storage value in step S1071. For example, if the intermediate total execution value of the function to which the brake trigger flag belongs is 7800, the target height is calculated according to a preset height mapping ratio: Target height (px) = Intermediate total execution value ÷ 10; 1px corresponds to 10 units of total execution value; Example: When the intermediate total execution value is 9200, the target height = 9200 ÷ 10 = 920px; when the intermediate total execution value is 6500, the target height = 650px. The agent applies the target height to the corresponding display column to ensure a precise correspondence between the column height and the total execution value of the function. Debuggers can intuitively judge the execution frequency of the variable through the column height.

[0060] 2. Dynamic adjustment of display column width: Important weight acquisition: Extract the current important weight of the calculation function to which the Boolean variable belongs. The initial weight comes from the function importance level library, and the weight after iteration comes from the optimization result of step S1074. For example, the important weight of the function to which the braking trigger flag belongs is 1.92. Target width calculation: The target width is calculated by adjusting the positive correlation function of the model using bar parameters. The formula is: Target width (px) = Base width (20px) × (1 + Importance weight × 0.5); The width limit range is set to 10px-50px (to avoid it being too narrow to be identifiable or too wide to occupy excessive display space). The calculation result is rounded to the nearest integer. Example: Brake trigger mark (importance weight 1.92): 20 × (1 + 1.92 × 0.5) = 20 × 1.96 = 39.2px, rounded to 39px; Air conditioner start sign (importance weight 0.96): 20 × (1 + 0.96 × 0.5) = 20 × 1.48 = 29.6px, rounded to 30px; Redundancy reserve flag (importance weight 0.5): 20 × (1 + 0.5 × 0.5) = 20 × 1.25 = 25px; Width Effectiveness and Visual Focus: The agent synchronizes the calculated target width to the bar chart of the IAR visualization interface. The bars for variables with high importance weight are displayed wider (with a larger visual share), while the bars for variables with low importance weight are displayed narrower (to reduce visual interference), thus achieving natural visual focus on the core variables.

[0061] In addition, the exception handling and IAR environment adaptation mechanism is as follows: 1. Data Missing Data Adaptation: If the intermediate total amount, important weight, or change frequency data of a Boolean variable is missing (e.g., a newly added custom variable has not been entered into the relevant library), the agent will automatically assign default values ​​(intermediate total amount is 3000 by default, important weight is 1.0 by default, and change frequency is 0.05Hz by default), and set the display bar color to dark purple, height to 300px, and width to 25px to ensure the integrity of the chart and not affect the overall debugging process; 2. IAR version compatibility: The agent automatically identifies the current software version (such as V8 / V9) through the IAR version detection API, and adjusts parameters such as color space (RGB / HSV) and bar graph rendering mode to ensure that it can be displayed normally in different versions of IAR EmbeddedWorkbench without compatibility issues; 3. Chart Interaction Function: Allows debugging personnel to click on the displayed column to view details (including variable name, intermediate running volume, change frequency, important weight, and associated function), and supports sorting and filtering by column height, column width, and color, further improving operational flexibility.

[0062] This embodiment also includes the following steps: Step S109: Obtain the preset breakpoint location and search for nearby execution breakpoints. 1. Precise Extraction of Preset Positions: The agent uses the IAR project file parsing interface to traverse all preset debug breakpoints inserted in step S107 and extracts the three-dimensional position information of each breakpoint: Line number, such as line 156 of the torque adjustment function in the IAR project; Offsets within functions, such as the position of the 28th instruction within the torque adjustment function, are adapted to IAR's function instruction indexing rules. Memory address, such as 0x080092C0, is the actual storage address of the variable / function after IAR compilation; All location information is stored in the IAR project's temporary cache (Breakpoint_Pos_List), forming a structured list of preset breakpoint locations that supports batch traversal processing.

[0063] 2. IAR-adaptive breakpoint search range definition: The agent calls the breakpoint configuration rule base to construct a two-dimensional search range with each preset position as the core: Line of code dimension: [preset line number - 5, preset line number + 5]. For example, when the preset position is line 156, the search range is lines 151-161. Memory address dimension: [preset memory address - 16, preset memory address + 16]. For example, when the preset address is 0x080092C0, the search range is 0x080092B0-0x080092D0. The two-dimensional search ensures coverage of minute offsets that may exist between lines of code and memory addresses in the IAR environment, avoiding omissions in breakpoint searches due to compilation optimizations.

[0064] 3. Proximity Execution Breakpoint Scanning and Statistics: The agent scans all valid execution breakpoints within the search range using IAR's C-SPYDebugAPI interface, including: Valid execution breakpoints remaining from historical debugging; The execution breakpoints were manually activated during this debugging process; During the scan, two types of invalid breakpoints are automatically filtered: first, breakpoints caused by code position offsets after IAR compilation, such as breakpoints whose line numbers no longer correspond to instructions after code modifications; second, breakpoint placeholders that were not completely removed, residual markers in the breakpoint management list that IAR software has not updated synchronously. Finally, the number of nearby valid execution breakpoints corresponding to each preset position is counted and denoted as `near_bp_count`. For example, if there are 2 valid execution breakpoints within the search range of line 156 at the preset position, then `near_bp_count` = 2.

[0065] Step S110: Quantity threshold judgment and automatic conversion of preset breakpoints 1. Reference Quantity Comparison Logic: The agent reads a preset reference quantity from the breakpoint configuration rule base (3 in this embodiment), and compares the near_bp_count of each preset position with the reference quantity one by one, forming two types of judgment results: If near_bp_count > reference number (e.g., 4 > 3): it is determined that the execution breakpoints in this area are already dense, no additional conversion is needed, and excessive IAR debugging resource consumption is avoided; If near_bp_count ≤ reference number (e.g., 2 ≤ 3): it is determined that the breakpoint coverage in this area is insufficient, and the preset debug breakpoints need to be converted into hardware breakpoints that can be executed by IAR.

[0066] 2. IAR-compatible execution breakpoint conversion: For preset debug breakpoints that meet the conversion conditions, the agent performs the following operations: Generate execution breakpoint instructions supported by the IAR debug kernel: Based on the target embedded chip architecture, such as the ARM Cortex-M series, generate BKPT hardware breakpoint instructions to replace the comment placeholders of the preset breakpoints; Call IAR's AddBreakpoint API to write the instruction to IAR's BreakpointManager, thus completing the conversion from a software placeholder to a hardware executable breakpoint. Record conversion log: The log format is / / [IAR Smart Breakpoint Conversion] Preset position: line {line number} | memory address: {address} | number of adjacent breakpoints: {quantity} | conversion status: successful, stored in the IAR project's debug log file (.log) for developers to trace.

[0067] 3. IAR Environment Breakpoint Conflict Avoidance: If a preset location is detected to overlap with an existing execution breakpoint during the conversion process, such as multiple breakpoints existing at the same line of code / memory address, the agent will handle it according to the following rules: Extract the important weights of the functions to which the overlapping breakpoints belong, which are derived from the iterative optimization results of step S1074; Retain breakpoints with higher weights and convert low-weight breakpoints into standby execution breakpoints, marked as / / [standby breakpoint] line {line number}-weight: {value}; Monitor the IAR debugging status. When a high-weight breakpoint is deleted or becomes invalid, automatically activate a backup breakpoint to ensure uninterrupted debugging coverage and avoid debugging anomalies caused by IAR breakpoint conflicts.

[0068] In addition, the IAR environment anomaly handling mechanism is as follows: 1. If the agent fails to call the IARAPI interface, such as due to insufficient permissions or IAR software not responding, the retry mechanism will be triggered immediately, up to 3 times. If the retry fails, the conversion process will be paused, the exception will be marked in the IAR project log, and the original state of the preset breakpoint will be preserved to avoid code corruption. 2. If the converted execution breakpoints exceed the breakpoint capacity of the IAR software (e.g., some IAR versions support a maximum of 8 hardware breakpoints), the agent will automatically prioritize retaining breakpoints for functions with high weight and convert low weight breakpoints into software breakpoints. IAR supports the __breakpoint() function instruction to ensure that debugging of core areas is not affected.

[0069] This optional step is a sub-step of the quantity threshold judgment and preset breakpoint automatic conversion in the aforementioned step S110: Step S111: Accurately Obtain the Number of Executions in a Single Debugging Session The intelligent agent listens for the end signal of a single full-run debugging session through IAR's C-SPYDebugAPI interface, including the completion of all execution breakpoint traversal, the developer clicking the StopDebugging button in IAR, and the debugging timeout being triggered. Upon response, it performs the following operations: 1. Extract the number of execution breakpoints that finally take effect during this debugging process, and record it as exec_bp_count. This number only counts execution breakpoints that have been successfully converted, have not been manually deleted, and are in a valid state. It automatically filters out spare breakpoints, invalid breakpoints (such as breakpoints whose positions have been offset after code modification), and inactive preset debugging breakpoints in the IAR breakpoint management list. 2. Store the obtained exec_bp_count to the debug data cache file (.dbug) of the IAR project and record it synchronously in the debug log. For example, after the conversion in step S110, 10 new execution breakpoints were added in this debug, combined with the 15 historical valid execution breakpoints, resulting in exec_bp_count=25.

[0070] Step S112: Calculate the ratio for dual-mode execution Method 1: Calculation of the ratio of the number of executions to the reference number of executions 1. The agent reads the preset reference execution amount from the reference quantity dynamic adjustment library, denoted as ref_exec_amount, with an initial value of 25; 2. Calculate the execution ratio using a standardized ratio formula, denoted as `exec_ratio`: `exec_ratio = exec_bp_count ÷ ref_exec_amount`. The result is rounded to two decimal places; if the result is greater than 2.0, it is rounded down to 2.0 to avoid excessive adjustment of the reference number due to an abnormal surge in the number of executions, exceeding the IAR breakpoint capacity limit. Example: When exec_bp_count=25, ref_exec_amount=25, exec_ratio=25÷25=1.00; When exec_bp_count=60 and ref_exec_amount=25, exec_ratio=2.00, triggering the upper limit limit.

[0071] Method 2: Calculation of percentage change in execution quantity 1. The agent extracts the number of valid execution breakpoints from the debugging log of the IAR project in the last single debugging session, and records it as last_exec_count. For example, last_exec_count=20 in the last debugging session. 2. Calculate the execution ratio (exec_ratio) using the percentage change formula: exec_ratio = |exec_bp_count - last_exec_count| ÷ last_exec_count. The result should be rounded to two decimal places. If the result is greater than 1.5, use 1.5 as the value to avoid abnormal ratios due to large code iterations, which could affect the stability of adjustments. Example: When exec_bp_count=25 and last_exec_count=20, exec_ratio=|25-20|÷20=0.25; When exec_bp_count=50 and last_exec_count=20, exec_ratio=1.50, triggering the upper limit limit.

[0072] Step S113: Dynamic adjustment and activation of reference quantity 1. Adjustment Logic and Formula Definition: The larger the execution ratio, the greater the deviation between the current number of execution breakpoints and the reference execution quantity, or the more significant the change from the historical quantity, requiring a larger adjustment of the reference quantity; conversely, a smaller adjustment is needed to ensure smooth adjustment. The adjustment formula is: new_ref_count = old_ref_count × (1 + execute_ratio × adjustment coefficient); where the adjustment coefficient is preset to 0.5 to balance the sensitivity and stability of breakpoint adjustment in the IAR environment, old_ref_count is the current reference quantity, and new_ref_count is the new reference quantity after adjustment; at the same time, new_ref_count must satisfy the adjustment lower limit ≤ new_ref_count ≤ adjustment upper limit, that is, 5 ≤ new_ref_count ≤ 40. If the calculation result exceeds the range, the corresponding boundary value is taken.

[0073] 2. Example of scene-specific adjustment: Scenario 1 (Calculation using Method 1, initial old_ref_count=25): If exec_bp_count=15, ref_exec_amount=25, then exec_ratio=0.60; new_ref_count = 25 × (1 + 0.60 × 0.5) = 25 × 1.3 = 32.5, rounded down to 33 (not exceeding the upper limit of 40, so it takes effect immediately). Scenario 2 (Calculation using Method 2, initial old_ref_count=25): If exec_bp_count=35, last_exec_count=20, then exec_ratio=0.75; new_ref_count = 25 × (1 + 0.75 × 0.5) = 25 × 1.375 = 34.375, rounded down to 34 (effective); Scenario 3 (too few executions, exec_bp_count=8): exec_ratio=8÷25=0.32, new_ref_count=25×(1+0.32×0.5)=25×1.16=29 (Maintaining a high reference count encourages subsequent breakpoint conversion); Scenario 4 (Too many executions, exec_bp_count=80): exec_ratio=2.00, new_ref_count=25×(1+2.00×0.5)=50. Since it exceeds the upper limit of 40, new_ref_count is ultimately set to 40 (to limit the excessive conversion of subsequent breakpoints).

[0074] 3. Reference Quantity Update Takes Effect: The agent synchronizes the calculated `new_ref_count` to the IAR-specific breakpoint configuration rule base, overwriting the original reference quantity, and uses it as the core threshold for quantity threshold judgment in step S110 of the next debugging process. Simultaneously, the reference quantity parameter is updated in the IAR project's configuration file (.ewp) to ensure that the adjustment results remain effective after the IAR software restarts. The adjustment process log (including adjustment time, `old_ref_count`, `exec_ratio`, and `new_ref_count`) is stored in the IAR debug log, allowing developers to manually roll back to historical reference quantities.

[0075] In addition, IAR environment adaptation and exception handling are as follows: 1. IAR version compatibility: The agent automatically identifies the software version (V8 / V9, etc.) through the IAR version detection API, and adjusts parameters such as ratio calculation precision and reference quantity storage path to ensure normal adjustment in different versions of IAR; 2. Handling missing data: If the count of the last execution breakpoint cannot be obtained, such as during the first debugging, automatically switch to method one for calculation; if exec_bp_count fails to be obtained, such as when the IAR debug log is corrupted, retain the original reference count, do not make any adjustments, and mark the exception in the IAR project log. 3. Chip resource adaptation: To address the differences in breakpoint handling capabilities among different automotive MCUs, the intelligent agent automatically adjusts the upper and lower limits of the reference quantity. For example, the upper limit for low-end chips is set to 30 to avoid exceeding hardware resource limitations.

[0076] This embodiment also includes the following steps: Step S114: Respond to the debug start command and start IAR single-step debugging. The agent listens for debugging start commands in real time via the IARC-SPY automated debugging API, including when developers manually click the "Start Debugging" button on the IAR interface, when automated test scripts are triggered, and when scheduled debugging tasks are triggered. Upon receiving the command, the agent performs the following initialization operations: 1. Forcefully disable the full-speed running mode of the IAR software and lock it in hardware-level single-step debugging mode to establish real-time communication with the debugging kernel of the embedded motion control chip; 2. Clear the IAR debug log cache and initialize the breakpoint trigger counter and code execution progress timer; 3. Obtain full execution permissions for motion control code, and be able to read breakpoint status in real time and execute control code line by line.

[0077] Step S115: Breakpoint count statistics and intelligent switching of debug modes. 1. Accurate statistics on the number of effective breakpoints The agent traverses all breakpoints in the IAR breakpoint management list, removes invalid breakpoints, overlapping breakpoints, and inactive preset breakpoints, and counts the total number of finally effective execution breakpoints, which is defined as the breakpoint count. This data is fully matched with the chip hardware breakpoint resources and the IAR debugging kernel's carrying capacity to ensure that the statistical results are true and valid.

[0078] 2. Intelligent judgment and switching between dual debugging modes The number of breakpoints obtained from the statistics is compared with the preset number of breakpoint references, and the agent directly controls the IAR debug kernel to switch execution modes: Mode 1: Looping and single-step debugging If the number of breakpoints is less than the reference number of breakpoints: the current scenario is determined to be a sparse breakpoint scenario with few core debugging nodes. It is necessary to check the code logic line by line and switch the agent to loop single-step debugging mode. Execution logic: Controls the IAR debug kernel to execute code line by line without time intervals until the program traversal is completed or an execution breakpoint is triggered, ensuring that no code branches or logical judgments are missed, which is suitable for fine-grained debugging of core security functions.

[0079] Mode 2: Timed single-step debugging If the number of breakpoints is greater than or equal to the number of breakpoint references: the current scenario is determined to be a breakpoint-intensive scenario with sufficient core debugging nodes. There is no need to execute line by line, and the agent switches to timed single-step debugging mode. Execution logic: The code execution is controlled according to the initial breakpoint time interval (500ms). After executing each line of code, the execution is paused for the corresponding duration before continuing, balancing debugging observability and execution efficiency.

[0080] Step S116: Ratio calculation and dynamic adaptive adjustment of breakpoint time interval The intelligent agent has built-in dual-mode ratio calculation logic, which automatically adapts to the debugging scenario and dynamically adjusts the breakpoint time interval in real time through the IAR debugging interface, achieving fine-grained intelligent control of the debugging rhythm. Adjustment Mode 1: Negative Correlation Adjustment Based on Breakpoint Ratio 1. Calculation of the ratio of breakpoints Breakpoint ratio = number of effective breakpoints ÷ number of reference breakpoints; this ratio directly reflects the density of the current breakpoints. The larger the ratio, the denser the breakpoint distribution.

[0081] 2. Negative correlation adjustment logic The breakpoint ratio and breakpoint time interval are strictly negatively correlated: the larger the breakpoint ratio, the denser the breakpoints, and the faster the debugging pace (smaller interval); the smaller the breakpoint ratio, the sparser the breakpoints, and the slower the debugging pace (larger interval). Adjustment formula: Target breakpoint time interval = Initial interval ÷ Breakpoint ratio; 3. Execution Example Number of breakpoint references = 20, initial interval = 500ms: Number of breakpoints = 40 → Breakpoint ratio = 2.0 → Target interval = 500 ÷ 2.0 = 250ms (high-speed debugging); Number of breakpoints = 10 → Breakpoint ratio = 0.5 → Target interval = 1000ms (low-speed fine-tuning).

[0082] Adjustment Mode 2: Positive Correlation Adjustment Based on Unexecuted Ratio 1. Ratio calculation not performed. Number of unexecuted breakpoints = Total number of valid breakpoints - Number of triggered breakpoints; Unexecuted ratio = Number of unexecuted breakpoints ÷ Number of breakpoint references; This ratio reflects the remaining workload of the breakpoint to be debugged. The larger the ratio, the heavier the remaining debugging workload.

[0083] 2. Positive correlation adjustment logic The non-execution ratio is strictly positively correlated with the breakpoint time interval: the larger the non-execution ratio, the more remaining breakpoints, and the debugging pace automatically speeds up (intervals decrease); the smaller the non-execution ratio, the fewer remaining breakpoints, and the debugging pace automatically slows down (intervals increase). Adjustment formula: Target breakpoint time interval = Initial interval × (1 - Non-execution ratio); 3. Execution Example Number of breakpoint references = 20, initial interval = 500ms: Unexecuted ratio = 0.8 → Target interval = 500 × (1 - 0.8) = 100ms (full-speed single-step debugging); Unexecuted ratio = 0.1 → Target interval = 450ms (low-speed observation and debugging).

[0084] 3. Boundary Protection Mechanism Regardless of the adjustment mode used, the agent will forcibly limit the calculated target breakpoint time interval to within the range of 100ms to 2000ms: If the calculation result is <100ms, it will be automatically assigned to 100ms to avoid the IAR interface refresh being too slow and chip debugging data being lost due to the interval being too small. If the calculation result is greater than 2000ms, it will be automatically assigned the value of 2000ms to avoid excessively large intervals that would lead to low debugging efficiency.

[0085] In addition, the IAR environment adaptation and exception handling mechanism is as follows: 1. IAR version compatibility The intelligent agent automatically detects the IAR software version (V8 / V9 / V10), adapts to different versions of C-SPY debugging interface commands, and adjusts parameters to be synchronized to the IAR debugging configuration panel in real time, without compatibility issues. 2. Chip resource adaptation For low-end automotive MCUs (with limited hardware breakpoint resources) and high-end domain controller chips, the number of breakpoint references and the interval range are automatically adjusted to avoid overloading the chip debugging core; 3. Exception interruption handling If breakpoint failures or program crashes occur during debugging, the agent immediately pauses the adjustment logic, restores the default 500ms interval, and marks the abnormal location in the IAR debugging log to ensure the stability of the debugging process.

[0086] This optional embodiment realizes fully automated intelligent control of the debugging rhythm of embedded motion control chip programs in the IAR development environment. It intelligently switches the debugging mode by the number of breakpoints and dynamically adjusts the execution interval by combining the two-dimensional ratio, perfectly balancing the integrity, efficiency and stability of debugging. It solves the pain points of traditional single-step debugging, which relies on manual labor, is inefficient and prone to missing logic, and greatly optimizes the automated debugging experience of motion control code in the IAR environment.

[0087] This application also discloses a debugging system for agent-based motion control code, including a processor, wherein the processor executes the steps of the agent-based motion control code debugging method as described in any of the above embodiments.

[0088] This application also discloses a storage medium storing a program that, when executed by a processor, implements the steps of the debugging method for the agent-based motion control code described in any of the above embodiments.

[0089] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for debugging motion control code based on an intelligent agent, characterized in that, Includes the following steps: The system establishes a connection between a pre-defined intelligent agent and pre-defined development software, and obtains read, write, and debugging permissions for the development software. Obtain the compilation instructions for the development software, obtain the motion control code based on the compilation instructions, and identify error characters, missing call characters, and newly added parameter variables from the motion control code based on a preset code rule base; Generate character markers corresponding to error characters or missing call characters, and insert the character markers into the motion control code in a preset comment format; The parameter variable is located to obtain its position. A preset debug pointer is inserted at the variable position. The debug pointer points to the storage address of the preset display content. The parameter variable is copied to the storage address and the compilation instructions are executed. The agent draws a variable graph based on the data in the storage address according to a preset display format and outputs it. The calculation function is extracted from the motion control code, the input parameters are identified from the calculation function, the running volume value is simulated based on the input parameters and the preset program simulation library, the function running volume of one execution is simulated based on the calculation process of the calculation function, and the total function running volume is calculated based on the running volume value and the function running volume. Specifically, the total function execution volume = execution volume value + single execution volume × number of executions, where the single execution volume is the function execution volume simulated for one execution based on the calculation process of the calculation function; Sort the total number of calculation functions in descending order, mark the functions with the highest preset number of calculation functions, and insert preset debugging breakpoints at the marked points; Obtain manual debugging operations, activate corresponding preset debugging breakpoints based on the manual debugging operations, convert the activated preset debugging breakpoints into execution breakpoints, and perform full-run debugging in a loop to traverse all execution breakpoints.

2. The debugging method for motion control code based on an intelligent agent according to claim 1, characterized in that, The step of sorting the total number of computational functions in descending order also includes the following sub-steps: Assign the total execution time of the function to the preset intermediate execution time; Obtain the debug start command, and in response to the debug start command, obtain the importance data of the calculation function. Match the corresponding weights according to the importance data as importance weights, and calculate the new function execution total corresponding to the calculation function based on the importance weights and the intermediate execution total. Obtain the debugging end command, and in response to the debugging end command, count the total number of times the breakpoints corresponding to all calculation functions are debugged and the number of times the breakpoints corresponding to a single calculation function are debugged, and calculate the percentage of breakpoints debugged for a single calculation function. The new importance weights of the calculation function are obtained by calculating the proportion of breakpoint debugging and the importance weights.

3. The debugging method for motion control code based on an intelligent agent according to claim 2, characterized in that, The step of the intelligent agent drawing a variable graph based on the data in the storage address according to a preset display format and outputting it also includes the following sub-steps: If the data is a non-Boolean variable, then the time axis is used as the horizontal axis, and the percentage change of the parameter variable is displayed by displaying curves of different colors, with the colors corresponding to the spectrum; The spectrum of the displayed color is positively adjusted according to the total amount of the function operation corresponding to the parameter variable. The larger the total amount of the function operation, the closer the wavelength of the spectrum is to the first light wavelength; the smaller the total amount of the function operation, the closer the wavelength of the spectrum is to the second light wavelength; the first light wavelength is greater than the second light wavelength. The transparency of the curve is adjusted according to the negative correlation of the importance weights. The greater the importance weight, the lower the transparency, and the smaller the importance weight, the higher the transparency.

4. The debugging method for motion control code based on an intelligent agent according to claim 2, characterized in that, The step of the intelligent agent drawing a variable graph based on the data in the storage address according to a preset display format and outputting it also includes the following sub-steps: If the data is a Boolean variable, the name of the parameter variable is used as the x-axis, and the total amount of function execution of the parameter variable is displayed by displaying bars of different colors. The bar chart has multiple display bars, and the display color of the display bars corresponds to the spectrum. Calculate the frequency of change of the Boolean variable, and adjust the spectrum of the displayed color according to the positive correlation of the frequency of change. The higher the frequency of change, the closer the wavelength of the spectrum is to the third light wavelength, and the lower the frequency of change, the closer the wavelength of the spectrum is to the fourth light wavelength. The second light wavelength is greater than the third light wavelength, and the third light wavelength is greater than the fourth light wavelength. The height of the display bar corresponds to the total amount of intermediate running; the width of the display bar in the bar chart is adjusted according to the positive correlation of the importance weight. The greater the importance weight, the wider the width, and the smaller the importance weight, the narrower the width.

5. The debugging method for motion control code based on intelligent agents according to claim 1, characterized in that, The method also includes the following steps: The location of the preset debug breakpoint is obtained as the preset location. Based on the preset breakpoint range, the execution breakpoints close to the preset location are searched. If the number of execution breakpoints corresponding to the preset location is greater than the preset reference number, then the preset debug breakpoints corresponding to the preset location will be converted into execution breakpoints.

6. The debugging method for motion control code based on an intelligent agent according to claim 5, characterized in that, The method also includes the following steps: The number of execution breakpoints corresponding to a single debugging session is the execution count. The ratio of the number of executions to the preset reference number of executions is the execution ratio. Alternatively, the percentage change in the number of executions can be calculated as the execution ratio. The reference quantity is adjusted based on the positive correlation of the execution ratio.

7. The debugging method for motion control code based on an intelligent agent according to claim 1, characterized in that, The method also includes the following steps: In response to the debug start command, initiate single-step debugging; The number of execution breakpoints is the breakpoint count. If the breakpoint count is less than the preset breakpoint reference count, single-step debugging is performed in a loop based on the development software. Otherwise, perform single-step debugging based on the preset breakpoint time interval; The ratio of the number of breakpoints to the reference number of breakpoints is the breakpoint ratio. The breakpoint time interval is adjusted based on the negative correlation of the breakpoint ratio. Alternatively, the ratio of the number of unexecuted breakpoints to the number of reference breakpoints can be calculated as the unexecuted ratio, and the breakpoint time interval can be adjusted based on the positive correlation of the unexecuted ratio.

8. The debugging method for motion control code based on an intelligent agent according to claim 7, characterized in that, The method also includes the following steps: If the number of breakpoints exceeds the preset maximum breakpoint value, a preset indicator code is inserted at the position of the execution breakpoint in the motion control code. The indicator code is used to output debugging indicator markers. Convert all execution breakpoints to preset debug breakpoints; The development software is used to perform full-run debugging, and the output debugging indicator marks are inserted into the corresponding data positions in the variable chart.

9. A debugging system for motion control code based on intelligent agents, characterized in that, Includes a processor, wherein the steps of the debugging method for agent-based motion control code as described in any one of claims 1-8 are executed.

10. A storage medium, characterized in that, The storage medium stores a program that, when executed by a processor, implements the steps of the debugging method for the agent-based motion control code as described in any one of claims 1-8.

Images