A simulation full-automatic breakpoint debugging verification method for a storage firmware algorithm

Abstract

This invention discloses a fully automated breakpoint debugging and verification method for storage firmware algorithms, belonging to the field of embedded firmware automated simulation testing technology. The method includes compiling the storage firmware and establishing a variable address index table based on the generated symbol file; configuring preset breakpoint numbers and breakpoint blocking logic on the service nodes to be verified in the storage firmware; and setting breakpoint control flags, stall state flags, and memory access paths independent of the storage firmware's service input / output paths between the simulation platform and the storage firmware. This invention achieves automated verification of the instantaneous running state of any preset service node in the firmware service by setting numbered breakpoints and blocking logic on the service nodes to be verified, and by using memory access paths independent of the storage firmware's service input / output paths to read variable data during the loop blocking period of the firmware service thread. This improves the verification coverage of the storage firmware service.

Description

Technical Field

[0001] This invention relates to the field of embedded firmware automated simulation testing technology, and in particular to a fully automated breakpoint debugging and verification method for storage firmware algorithms. Background Technology

[0002] With the continuous development of solid-state drives, embedded memories, and high-performance storage controllers, the algorithms undertaken by storage firmware, such as address mapping, wear leveling, garbage collection, error recovery, and protocol processing, are becoming increasingly complex. Their operation is characterized by strong timing, concurrency, and hardware coupling. The debugging and verification of storage firmware algorithms has gradually evolved from relying on physical samples and manual step-by-step debugging to relying on simulation environments to reproduce business scenarios, observe internal states, and conduct automated testing. Furthermore, it is being integrated with continuous integration systems to improve the coverage of abnormal scenarios, the efficiency of defect location, and the consistency of version regression verification, thereby meeting the R&D needs of rapid iteration and multi-platform adaptation of storage firmware.

[0003] Existing automated verification of storage firmware typically relies on firmware business logic to obtain variable data and runtime status. To ensure continuous business execution, breakpoints that halt business threads are usually not set. Therefore, for short-lived transient states, test scripts often struggle to obtain the internal variable data corresponding to the target business node in a timely manner, resulting in some runtime states not being effectively verified and low verification coverage. If breakpoints are set to capture these transient states, variable readings that rely on firmware business thread responses may fail to execute due to business thread stagnation. Furthermore, existing methods lack automatic coordination between breakpoint triggering, variable reading, result verification, and runtime recovery, still resulting in significant manual intervention and difficulty in reproducing verification results. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a fully automated breakpoint debugging and verification method for storage firmware algorithms to solve the problems of difficulty in verifying the instantaneous running state in firmware business logic through automated scripts, difficulty in stably reading variable data after firmware business threads have stopped, and difficulty in automatically closing the breakpoint debugging and verification process.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0007] This invention provides a fully automated breakpoint debugging and verification method for storage firmware algorithms, comprising: compiling the storage firmware and establishing a variable address index table based on the generated symbol file; configuring preset breakpoint numbers and breakpoint blocking logic on the service node to be verified in the storage firmware; setting a breakpoint control flag, a stall state flag, and a memory access path independent of the storage firmware's service input / output path between the simulation platform and the storage firmware; the test platform sending a target breakpoint trigger command to the simulation platform; the simulation platform writing the target breakpoint number into the breakpoint control flag through the memory access path; when the storage firmware executes to the service node to be verified, comparing the read breakpoint control flag with the preset breakpoint number corresponding to the service node to be verified; updating the stall state flag when they match; and causing the firmware service thread executing the service node to be verified to enter a loop blocking state, continuously reading the breakpoint during the loop blocking process. Upon detecting an update to the stall state flag, the simulation platform sends a breakpoint trigger completion signal to the test platform. In response, the test platform sends a variable read request. The simulation platform determines the target access address of the variable to be read based on the variable address index table and the memory base address of the storage firmware. While the firmware business thread remains in a loop, the platform directly reads the variable data at the target access address via the memory access path. This reading of the variable data does not invoke the firmware business thread in the loop. The test platform compares the read variable data with the corresponding preset verification conditions to obtain the breakpoint verification result. After obtaining the breakpoint verification result, the simulation platform clears the breakpoint control flag via the memory access path. Upon detecting the clearing of the breakpoint control flag during the loop blocking process, the storage firmware resets the stall state flag, exits the loop blocking, and resumes the scheduling of the firmware business thread.

[0008] As a preferred embodiment of the fully automated breakpoint debugging and verification method for storage firmware algorithms described in this invention, the step of compiling the storage firmware and establishing a variable address index table based on the generated symbol file includes:

[0009] During the firmware compilation phase, debug symbol information is preserved, and a symbol file containing firmware variable symbol information is generated.

[0010] The variable name, the program offset address of the target structure, the offset address of the members in the structure and the data length of each observed variable are analyzed to establish the correspondence and form a variable address index table.

[0011] As a preferred embodiment of the fully automated breakpoint debugging and verification method for storage firmware algorithms described in this invention, the step of configuring preset breakpoint numbers and breakpoint blocking logic on the service node to be verified in the storage firmware includes:

[0012] The preset breakpoint numbers corresponding to each service node to be verified are enumerated by macro definition. A general breakpoint function is inserted at the firmware code position corresponding to each service node to be verified, and the corresponding preset breakpoint number is used as the input parameter of the general breakpoint function, so that the firmware code position corresponding to each service node to be verified is associated with the preset breakpoint number.

[0013] Construct a breakpoint information maintenance table to associate each preset breakpoint number with the corresponding firmware code location, the business module to which it belongs, the name of the variable to be observed, the length of the variable data, and the preset verification conditions;

[0014] In the general breakpoint function, the breakpoint control flag is read and compared with the preset breakpoint number of the input general breakpoint function. When the two match, the stall state flag is updated and the firmware business thread executing the business node to be verified enters a loop blocking. During the loop blocking process, the breakpoint control flag is continuously read until the breakpoint control flag is detected to have changed to a non-trigger state value. The stored firmware determines that the breakpoint control flag has been cleared and exits the loop blocking.

[0015] As a preferred embodiment of the fully automated breakpoint debugging and verification method for storage firmware algorithms described in this invention, the step of setting breakpoint control flags, stall state flags, and memory access paths independent of the storage firmware's business input / output paths between the simulation platform and the storage firmware includes:

[0016] In the shared memory space accessed by the simulation platform and the storage firmware, the shared memory addresses are configured for the breakpoint control flag and the stall state flag respectively through address mapping.

[0017] Configure the breakpoint control flag to be written by the simulation platform and read by the storage firmware, and configure the stall state flag to be written by the storage firmware and read by the simulation platform;

[0018] Configure a memory access interface in the simulation platform so that the simulation platform can access the storage area corresponding to the breakpoint control flag, the stall state flag and the target access address through the memory access interface, without going through the storage firmware business input and output path, thus forming a memory access path independent of the storage firmware business input and output path.

[0019] As a preferred embodiment of the fully automated breakpoint debugging and verification method for storage firmware algorithms described in this invention, the simulation platform determines the target access address of the variable to be read based on the variable address index table and the memory base address of the storage firmware, including:

[0020] Obtain a variable read request sent by the test platform, wherein the variable read request includes the name of the variable to be read;

[0021] Obtain the base address of the storage firmware's runtime memory;

[0022] Based on the name of the variable to be read, retrieve the variable address index table to obtain the program offset address of the target structure to which the variable to be read belongs, the offset address of the member in the structure corresponding to the variable to be read, and the data length.

[0023] The target access address of the variable to be read is obtained by summing the base address of the storage firmware's runtime memory, the program offset address of the target structure, and the offset address of the member in the structure corresponding to the variable to be read.

[0024] As a preferred embodiment of the fully automated breakpoint debugging and verification method for storage firmware algorithms described in this invention, the step of directly reading variable data at the target access address through the memory access path during the period when the firmware business thread remains blocked in a loop includes:

[0025] While the firmware business thread remains blocked in a loop, the simulation platform accesses the storage area corresponding to the target access address through the memory access path.

[0026] Based on the data length corresponding to the variable to be read in the variable address index table, read the variable data from the target access address and send the read variable data to the test platform;

[0027] The testing platform compares the read variable data with the corresponding preset verification conditions to obtain the breakpoint verification results.

[0028] As a preferred embodiment of the fully automated breakpoint debugging and verification method for storage firmware algorithms described in this invention, the simulation platform clears the breakpoint control flag through the memory access path. When the storage firmware detects that the breakpoint control flag has been cleared during a loop blocking process, it resets the stall state flag and exits the loop blocking, resuming the scheduling of the firmware business thread. This includes:

[0029] After obtaining the breakpoint verification result, the simulation platform writes a non-triggering state value to the breakpoint control flag through the memory access path to clear the breakpoint control flag.

[0030] The storage firmware continuously reads the breakpoint control flag during the loop blocking process. When it detects that the breakpoint control flag has changed to a non-triggering state value, it determines that the breakpoint control flag has been cleared and resets the stall state flag.

[0031] The storage firmware exits the loop blocking, resumes the scheduling of the firmware business thread, and continues to execute the business process after the business node to be verified.

[0032] As a preferred embodiment of the fully automated breakpoint debugging and verification method for storage firmware algorithms described in this invention, it further includes a breakpoint configuration recovery step under power failure and restart scenarios:

[0033] Before performing the power failure and restart test, the simulation platform saves the preset breakpoint number, the information of the variable to be observed, and the preset verification conditions for the business node to be verified, forming breakpoint configuration data.

[0034] The information of the variable to be observed includes the name of the variable to be observed and the length of the variable data;

[0035] After the storage firmware restarts and before the storage firmware executes to the corresponding business node to be verified, the simulation platform loads the breakpoint configuration data and writes the preset breakpoint number in the breakpoint configuration data into the breakpoint control identifier through the memory access path.

[0036] When the storage firmware execution reaches the corresponding business node to be verified, it compares the read breakpoint control flag with the preset breakpoint number corresponding to the business node to be verified. When the two match, it updates the stall state flag and causes the firmware business thread executing the business node to enter a loop blocking state, so as to complete variable data reading and breakpoint verification while the firmware business thread remains in a loop blocking state.

[0037] As a preferred embodiment of the fully automated breakpoint debugging and verification method for storage firmware algorithms described in this invention, it further includes:

[0038] According to the preset test process, multiple business nodes to be verified are determined, and the preset breakpoint numbers corresponding to each business node to be verified are obtained in sequence.

[0039] For each business node to be verified, the test platform sends the corresponding target breakpoint trigger command to the simulation platform in sequence. The simulation platform executes the operations of writing the target breakpoint number into the breakpoint control identifier, detecting the stall state marker, reading variable data through the memory access path, and clearing the breakpoint control identifier in sequence. The test platform compares the read variable data with the corresponding preset verification conditions in sequence to obtain the breakpoint verification result for each business node to be verified.

[0040] The breakpoint triggering information, variable access information, and breakpoint verification results for each business node to be verified are summarized to generate a firmware algorithm verification report.

[0041] As a preferred embodiment of the fully automated breakpoint debugging and verification method for storage firmware algorithms described in this invention, it further includes a variable modification verification step:

[0042] While the firmware business thread remains blocked in a loop, the test platform determines the variable to be modified and the corresponding target variable value according to the preset test scenario, and sends a variable modification request including the name of the variable to be modified and the target variable value to the simulation platform.

[0043] The simulation platform determines the target access address of the variable to be modified based on the variable address index table and the memory base address of the stored firmware, and writes the target variable value to the target access address of the variable to be modified through the memory access path. The writing of the target variable value does not call the firmware business thread that is in a loop blocking state.

[0044] After writing the target variable value, the simulation platform clears the breakpoint control flag through the memory access path. When the storage firmware detects that the breakpoint control flag has been cleared during the loop blocking process, it resets the stall state flag and exits the loop blocking, restores the scheduling of the firmware business thread, and continues to execute the corresponding business process according to the written target variable value.

[0045] The test platform sends the target breakpoint trigger command corresponding to the subsequent service node to be verified to the simulation platform. The simulation platform writes the target breakpoint number corresponding to the subsequent service node to be verified into the breakpoint control flag through the memory access path, so that the storage firmware enters a loop blocking when it executes to the subsequent service node to be verified.

[0046] During the period when the firmware business thread remains blocked in a loop, the simulation platform determines the target access address of the variable to be read corresponding to the business node to be verified according to the variable address index table and the memory base address of the stored firmware, and directly reads the variable data at the target access address through the memory access path. The test platform compares the read variable data with the corresponding preset verification conditions to obtain the breakpoint verification result, so as to verify the firmware algorithm execution status after writing the target variable value.

[0047] The beneficial effects of this invention are as follows: By setting numbered breakpoints and blocking logic on the service nodes to be verified, and by using a memory access path independent of the storage firmware service input / output path to read variable data during the loop blocking of the firmware service thread, the internal state at the moment of stagnation can be stably obtained, thus improving the accuracy of breakpoint verification; by automatically linking symbol indexing, breakpoint triggering, stagnation confirmation, variable verification, and breakpoint release, the closed-loop execution of the breakpoint debugging and verification process can be achieved, reducing manual intervention and improving verification efficiency and result reproducibility. Attached Figure Description

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

[0049] Figure 1 This is a flowchart of a fully automated breakpoint debugging and verification method for simulation of storage firmware algorithms.

[0050] Figure 2Flowchart for preparing configurations for breakpoint debugging.

[0051] Figure 3 This is a flowchart for breakpoint triggering and variable reading verification.

[0052] Figure 4 This is a flowchart of the breakpoint release and firmware business thread recovery process. Detailed Implementation

[0053] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0054] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0055] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0056] Reference Figures 1-4 This is one embodiment of the present invention, which provides a fully automated breakpoint debugging and verification method for storage firmware algorithms, including the following steps:

[0057] S1. Compile the storage firmware and establish a variable address index table based on the generated symbol file. Configure preset breakpoint numbers and breakpoint blocking logic on the service nodes to be verified in the storage firmware. Set breakpoint control flags, stall status flags, and memory access paths independent of the service input / output paths of the storage firmware between the simulation platform and the storage firmware.

[0058] It should be noted that the fully automated breakpoint debugging and verification environment includes a test platform, a simulation platform, and storage firmware running on the simulation platform; the test platform is responsible for organizing the test process and sending breakpoint trigger instructions and variable read requests to the simulation platform; the simulation platform is responsible for loading the storage firmware, maintaining the simulation address space, and performing memory access; the storage firmware executes the business nodes to be verified according to the firmware business process.

[0059] Before compiling the storage firmware, the service nodes to be verified are determined based on the firmware code locations where the internal states need to be observed in the testing process. A unique preset breakpoint number is assigned to each service node to be verified. The preset breakpoint number is represented by the same data type as the breakpoint control identifier, indicating that the value of the non-triggered state is distinguished from each preset breakpoint number. The preset breakpoint numbers are enumerated through macro definitions, and a general breakpoint function is inserted at the firmware code location corresponding to the service node to be verified, with the corresponding preset breakpoint number as the parameter of the general breakpoint function. After the compiler expands the macro definitions, the preset breakpoint numbers are compiled to the corresponding code locations along with the general breakpoint functions, thus forming a correspondence between the firmware code locations and preset breakpoint numbers in the current firmware executable image.

[0060] The general breakpoint function configures the access action of the breakpoint control identifier, the comparison action of the preset breakpoint number, the update action of the stall state flag, and the loop blocking action of the firmware business thread according to the shared memory address mapping relationship between the breakpoint control identifier and the stall state flag. When the general breakpoint function is called, it obtains the current identifier value from the mapping address corresponding to the breakpoint control identifier and compares the current identifier value with the preset breakpoint number passed as a function parameter.

[0061] 1) When the obtained current identifier value is equal to the preset breakpoint number, the general breakpoint function updates the stall state flag to the breakpoint stall state and controls the firmware business thread executing the current business node to be verified to enter a loop blocking state. During the loop blocking period, the firmware business thread continuously obtains the current identifier value from the mapping address corresponding to the breakpoint control identifier, and remains loop blocking until the breakpoint control identifier changes to a non-trigger state value. When the breakpoint control identifier changes to a non-trigger state value, the firmware business thread resets the stall state flag, ends the loop blocking state, and continues to execute the firmware business process after the current business node to be verified.

[0062] 2) When the obtained current identifier value is not equal to the preset breakpoint number, the general breakpoint function does not update the stall state flag, the firmware business thread executing the current business node to be verified does not enter the loop blocking, and after the general breakpoint function ends execution, the firmware business thread continues to execute the firmware business process after the current business node to be verified.

[0063] The code configuration for the above processing logic is completed during the preparation phase. Comparison, update, and loop blocking actions occur when the storage firmware executes to the corresponding business node to be verified.

[0064] The testing platform establishes and saves a breakpoint information maintenance table for each configured business node to be verified. Each record in the breakpoint information maintenance table includes a preset breakpoint number, firmware code location, business module, name of the variable to be observed, variable data length, and preset verification conditions. The name of the variable to be observed and the preset verification conditions come from the test cases saved by the testing platform. The preset verification conditions are represented by the variable value judgment rules set in the test cases for the corresponding variable to be observed, and correspond to the name of the variable to be observed in the same record of the breakpoint information maintenance table. The preset breakpoint number establishes a correspondence between the target breakpoint specified by the testing platform and the firmware code location. The name of the variable to be observed and the variable data length provide variable retrieval content for subsequent variable read requests. The preset verification conditions provide the testing platform with the basis for comparing variable data. The testing platform calls the records in the breakpoint information maintenance table according to the test process to determine the target breakpoint number, name of the variable to be observed, and preset verification conditions corresponding to each verification, and uses the name of the variable to be observed as the variable name specified in the subsequent variable read request.

[0065] After configuring breakpoint code, the firmware source code is compiled using the compilation toolchain corresponding to the stored firmware, and debugging symbol information is retained in the compilation options. The compilation toolchain generates symbol files while generating the firmware executable image. The symbol files record the variable names, link addresses, and data lengths of firmware variables. After the firmware executable image is loaded onto the simulation platform, the simulation platform obtains the starting load address of the firmware executable image in the simulation address space from the firmware loading configuration and determines the starting load address as the memory base address of the stored firmware. The symbol files are loaded by the simulation platform before the test is performed and are not transmitted through the storage firmware business input / output path. In this embodiment, the firmware variables included in the variable address index table are variable data objects with determined link addresses and data lengths in the symbol files. The variable names use the complete symbol names recorded in the symbol files so that each variable name corresponds to the program offset address of the target structure, the offset address of the members in the structure, and the data length. The link base address is obtained from the link configuration file used by the compilation toolchain.

[0066] The simulation platform parses the target structure and the symbol information corresponding to each member variable in the target structure according to the record format of the symbol file. Taking the target structure as index_table as an example, the simulation platform obtains the link address of the target structure index_table in the storage firmware executable image from the symbol file and the corresponding link information, and obtains the link base address corresponding to the storage firmware executable image. Based on the link address and link base address of the target structure, the platform determines the in-program offset address of the target structure relative to the starting position of the storage firmware executable image.

[0067] Let the link address of the target structure in the stored firmware executable image be... The link base address for the stored firmware executable image is The intraprogram offset address of the target structure relative to the starting position of the stored firmware executable image is: ,but:

[0068] ;

[0069] in, This indicates the link address of the target structure in the stored firmware executable image, in byte address units; This indicates the link base address for storing the firmware executable image, in byte address units; This represents the intra-program offset address of the target structure relative to the starting position of the stored firmware executable image, in byte address units.

[0070] The simulation platform further analyzes the structure member information corresponding to each observed variable within the target structure; for the first... Let there be three variables to be observed, and denote their offset addresses relative to the starting address of the target structure as the offset addresses of the members within the structure. The corresponding data length is recorded as The simulation platform uses the name of the variable to be observed as the search term to find the offset address of the target structure within the program. Offset address of member in the structure corresponding to the variable to be observed and data length Establish associations to form a variable address index table.

[0071] When a variable read request is subsequently received, the simulation platform retrieves the variable address index table based on the name of the variable to be observed specified in the variable read request to obtain the program offset address of the target structure. Offset address of member in the structure corresponding to the variable to be observed and data length This provides the target access address for subsequently determining the variables to be observed.

[0072] The simulation platform determines the shared memory space accessible to both the simulation platform and the storage firmware based on the simulation memory mapping configuration. It allocates shared memory addresses from this space for breakpoint control flags and stall state flags, and maps these allocated addresses to the simulation address space of the storage firmware. Breakpoint control flags are configured to be written by the simulation platform and retrieved by the storage firmware, while stall state flags are configured to be written by the storage firmware and retrieved by the simulation platform. The data unit for the breakpoint control flag uses a non-triggered state value to represent the untriggered state and a preset breakpoint number to represent the triggered state of the corresponding service node to be verified. The data unit for the stall state flag uses the firmware running state value and the breakpoint stall state value to represent the current state of the firmware service thread. Different encodings are used for breakpoint stagnation state values. In this embodiment, the storage firmware defines the mapping data corresponding to the breakpoint control identifier and the stagnation state marker as a volatile access object, so that the firmware business thread accesses the corresponding mapping address each time it obtains the breakpoint control identifier, without reusing the identifier value obtained previously. After the simulation platform completes the writing of the breakpoint control identifier, the updated identifier value is provided to the storage firmware through the shared memory address mapping relationship. When initializing the simulation environment, the simulation platform sets the breakpoint control identifier to a non-triggering state value, and the storage firmware sets the stagnation state marker to the firmware running state when it starts. The breakpoint control identifier subsequently carries the target breakpoint number specified by the test platform, and the stagnation state marker subsequently indicates whether the firmware business thread has entered a loop blocking state.

[0073] The simulation platform is configured with a memory access interface for the simulation address space. This interface includes data acquisition and data writing functions. The data acquisition function receives the access address and data length, locates the corresponding storage area in the simulation address space according to the access address, and extracts consecutive bytes of data corresponding to the data length from the storage area. The data writing function receives the access address, data length, and data to be written, locates the corresponding storage area in the simulation address space according to the access address, and writes the data to be written into a consecutive byte range corresponding to the data length. When the memory access interface accesses a shared memory address marked by a breakpoint control flag, the data writing function completes the writing of the target breakpoint number and the non-triggering state value. When the memory access interface accesses a shared memory address marked by a stall state flag, the data acquisition function obtains the current state of the firmware business thread. When the memory access interface accesses a subsequently determined target access address, the data acquisition function obtains the corresponding variable data.

[0074] The memory access interface call chain does not generate storage firmware business commands, does not enter the storage firmware business input / output path, and does not require the firmware business thread to handle memory access requests, thus forming a memory access path independent of the storage firmware business input / output path. Control requests and variable read requests initiated by the test platform are first sent to the simulation platform, and then the simulation platform calls the memory access interface to complete the corresponding access. The test platform does not directly operate on the shared memory space. After the firmware business thread enters a loop block, the simulation platform still accesses the corresponding storage area according to the target access address and data length. After the breakpoint verification is completed, the simulation platform still updates the breakpoint control flag to a non-triggered state value through the same memory access path.

[0075] After completing the above configuration, the variable address index table provides the program offset address of the target structure, the offset address of the members in the structure, and the data length to the subsequent target access address determination process. The preset breakpoint number and breakpoint blocking logic provide the execution basis for the subsequent breakpoint matching and thread stagnation process. The breakpoint control flag and stagnation status flag respectively carry the breakpoint control status and firmware stagnation status. The memory access path is responsible for writing the breakpoint control flag, obtaining the stagnation status, accessing variable data, and clearing the breakpoint control flag. The above configuration results together constitute the implementation basis for subsequent breakpoint triggering, variable verification, and firmware business thread recovery scheduling.

[0076] S2. The test platform sends a target breakpoint trigger command to the simulation platform. The simulation platform writes the target breakpoint number into the breakpoint control flag through the memory access path. When the stored firmware executes to the service node to be verified, it compares the read breakpoint control flag with the preset breakpoint number corresponding to the service node to be verified. When the two match, it updates the stagnation status flag and causes the firmware service thread executing the service node to enter a loop blocking. During the loop blocking process, it continuously reads the breakpoint control flag. After the simulation platform detects the update of the stagnation status flag, it sends a breakpoint trigger completion signal back to the test platform.

[0077] It should be noted that the test platform calls the record corresponding to the current test process in the breakpoint information maintenance table, obtains the preset breakpoint number corresponding to the business node to be verified from the called record, and determines the preset breakpoint number as the target breakpoint number for this breakpoint debugging and verification. The breakpoint information maintenance table has established a correspondence between each preset breakpoint number and the firmware code location, the business module to which it belongs, the name of the variable to be observed, the variable data length, and the preset verification conditions. The test platform selects the preset breakpoint number corresponding to the current test process from the breakpoint information maintenance table as the target breakpoint number, and before the stored firmware executes to the business node to be verified, it generates a target breakpoint trigger instruction carrying the target breakpoint number and sends the target breakpoint trigger instruction to the simulation platform. The target breakpoint number limits the business node to be verified that needs to be stopped this time. The name of the variable to be observed and the preset verification conditions in the breakpoint information maintenance table are kept in the test platform for variable access and breakpoint verification calls after the breakpoint is triggered.

[0078] The simulation platform receives the target breakpoint trigger command, extracts the target breakpoint number from the command, and calls the shared memory address mapping relationship corresponding to the breakpoint control identifier to determine the access address of the breakpoint control identifier in the simulation address space. The data length and data encoding method of the breakpoint control identifier are determined by the shared memory address mapping configuration jointly adopted by the simulation platform and the storage firmware. The simulation platform generates the data to be written corresponding to the target breakpoint number according to the data length and data encoding method. The simulation platform calls the data length and data encoding method of the breakpoint control identifier from the shared memory address mapping configuration, converts the target breakpoint number into the data to be written that conforms to the data length and data encoding method, and then calls the data write function in the memory access interface to submit the access address, data length, and data to be written of the breakpoint control identifier to the data write function. The data write function locates the corresponding data unit in the shared memory space according to the access address of the breakpoint control identifier, writes the data to be written to the data unit, and updates the breakpoint control identifier from a non-triggered state value to the target breakpoint number.

[0079] The target breakpoint number is written via a memory access path independent of the storage firmware's business input / output path. When writing the breakpoint control identifier, the simulation platform does not generate storage firmware business commands, call the storage firmware's business command processing function, or require the firmware business thread to respond to the target breakpoint trigger instruction. The breakpoint control identifier access address on the simulation platform side and the breakpoint control identifier mapping address on the storage firmware side point to the same data unit in the shared memory space. After the simulation platform writes the target breakpoint number to the data unit, the storage firmware obtains the target breakpoint number from the mapping address corresponding to the breakpoint control identifier. The target breakpoint number remains unchanged in the breakpoint control identifier until the simulation platform writes a non-triggering state value to the breakpoint control identifier after breakpoint verification is completed.

[0080] After writing the target breakpoint number, the storage firmware continues to execute according to the firmware business process. When the storage firmware executes to the firmware code location configured with a general breakpoint function, it calls the general breakpoint function and uses the preset breakpoint number corresponding to the current business node to be verified as the function parameter. The general breakpoint function obtains the current identifier value from the mapping address corresponding to the breakpoint control identifier, interprets the obtained byte data according to the data type of the breakpoint control identifier, and then compares the current identifier value with the preset breakpoint number in the function parameter. The current identifier value comes from the writing result of the breakpoint control identifier by the simulation platform, and the preset breakpoint number comes from the general breakpoint function parameter configured at the current firmware code location. The comparison result determines whether the current firmware business thread enters a loop blocking state.

[0081] 1) When the obtained current identifier value is equal to the preset breakpoint number, the storage firmware determines that the current business node to be verified is the business node specified by the target breakpoint number; the general breakpoint function first updates the stagnation state flag from the firmware running state value to the breakpoint stagnation state value, and after the update is completed, directly controls the firmware business thread executing the current business node to be verified to enter a loop blocking; the stagnation state flag update and the loop blocking entry are executed continuously. After the stagnation state flag is updated, the firmware business thread no longer executes the firmware code after the current business node to be verified, but continues to obtain the breakpoint control flag during the loop blocking process; after the firmware business thread enters the loop blocking, it does not return to the business process after the current business node to be verified, and re-obtains the current identifier value from the mapping address corresponding to the breakpoint control flag in each loop; while the breakpoint control flag maintains the target breakpoint number, the firmware business thread continues to execute the loop blocking and does not call the storage firmware business input / output path to process subsequent business requests.

[0082] During the loop blocking period, the breakpoint control flag and the stall state flag maintain different functions. The target breakpoint number in the breakpoint control flag maintains the loop blocking condition of the firmware business thread, while the breakpoint stall state value in the stall state flag indicates to the simulation platform that the firmware business thread has reached the target business node and entered the loop blocking. The firmware business thread continuously acquires the breakpoint control flag but does not decide to exit the loop blocking based on the stall state flag. The stall state flag is used by the simulation platform to determine the breakpoint triggering result and does not change the loop judgment relationship of the firmware business thread on the breakpoint control flag. When the breakpoint control flag has not yet changed to a non-triggered state value, the firmware business thread remains in loop blocking, waiting for subsequent variable access and breakpoint verification to complete.

[0083] 2) When the current flag value is not equal to the preset breakpoint number, the current firmware code position is not the business node to be verified specified by the target breakpoint number; the general breakpoint function does not update the stall state flag, does not control the firmware business thread to enter a loop block, and ends the current call after the comparison is completed. The firmware business thread continues to execute the firmware business process after the current business node; when the storage firmware is subsequently executed to other firmware code positions configured with general breakpoint functions, the comparison is re-executed using the preset breakpoint number of the corresponding firmware code position; the target breakpoint number in the breakpoint control flag remains unchanged during this period until the storage firmware is executed to the business node to be verified where the preset breakpoint number is equal to the target breakpoint number.

[0084] After writing the target breakpoint number into the breakpoint control identifier, the simulation platform calls the shared memory address mapping relationship corresponding to the stagnation state marker to determine the access address of the stagnation state marker in the simulation address space. The data length of the stagnation state marker, the data encoding relationship corresponding to the firmware running status value and the breakpoint stagnation state value are already configured in the shared memory address mapping relationship. The simulation platform extracts the byte data of the stagnation state marker according to the data length and determines the current status value of the stagnation state marker according to the data encoding relationship. The simulation platform accesses the stagnation state marker through the data acquisition function in the memory access interface. The data acquisition function locates the corresponding data unit in the shared memory space according to the access address of the stagnation state marker, extracts the byte data corresponding to the data length of the stagnation state marker from the data unit, and converts the extracted byte data into the current status value of the stagnation state marker. The process of acquiring the stagnation state marker does not go through the storage firmware business input / output path and does not call the firmware business thread to process the status query request.

[0085] The simulation platform compares the current state value acquired each time with the breakpoint stagnation state value according to the state code of the stagnation state marker, and performs the following processing based on the comparison result:

[0086] 1) When the current state value of the stall state marker is equal to the stall state value of the breakpoint, the simulation platform determines that the storage firmware has been executed to the business node to be verified corresponding to the target breakpoint number, and determines that the firmware business thread executing the business node to be verified has entered a loop blocking state. The simulation platform stops the stall state detection during this breakpoint triggering process and generates a breakpoint triggering completion signal. The breakpoint triggering completion signal indicates that the stall state marker corresponding to the current target breakpoint has been updated to the breakpoint stall state value, and indicates that the firmware business thread executing the business node to be verified has entered a loop blocking state according to the breakpoint blocking logic. After the simulation platform sends the breakpoint triggering completion signal to the test platform, the breakpoint control identifier continues to maintain the target breakpoint number, the stall state marker continues to maintain the breakpoint stall state value, and the firmware business thread continues to remain in a loop blocking state, thereby preserving the firmware execution position and thread state required for subsequent variable access.

[0087] 2) When the current status value of the stall state marker is equal to the firmware running status value, the simulation platform determines that the storage firmware executing the target breakpoint trigger instruction has not yet entered a loop blocking state, does not generate a breakpoint trigger completion signal, and continues to obtain the current status value of the stall state marker through the memory access path; when the storage firmware executes to the firmware code position where the preset breakpoint number is not equal to the target breakpoint number, the stall state marker maintains the firmware running status value, and the simulation platform continues to perform stall state detection; after the storage firmware executes to the service node to be verified where the preset breakpoint number is equal to the target breakpoint number and updates the stall state marker, the simulation platform obtains the breakpoint stall state value in the subsequent status acquisition process, and generates a breakpoint trigger completion signal and sends it to the test platform according to the processing method when the current status value of the stall state marker is equal to the breakpoint stall state value.

[0088] The target breakpoint number and the stall status flag together define the breakpoint triggering result. The target breakpoint number is compared with the preset breakpoint number of each service node to be verified to define the code position where the firmware service thread enters the loop blocking. The stall status flag defines the time when the simulation platform sends the breakpoint trigger completion signal to the test platform by the change between the firmware running status value and the breakpoint stall status value. The simulation platform first writes the target breakpoint number to the breakpoint control identifier, and then the stored firmware updates the stall status flag according to the number comparison result. The simulation platform only sends the breakpoint trigger completion signal after obtaining the breakpoint stall status value, thereby avoiding the test platform from initiating subsequent variable accesses before the firmware service thread has entered the loop blocking.

[0089] When the breakpoint trigger completion signal is sent to the test platform, the current processing results in four items: the target breakpoint number remains at the breakpoint control identifier, the breakpoint stall state value remains at the stall state marker, the firmware business thread remains in a loop blocking state, and the test platform obtains the breakpoint trigger completion signal. The test platform uses the breakpoint trigger completion signal as the execution condition for sending a variable read request. The simulation platform continues to access the variable data using a memory access path independent of the storage firmware business input / output path. The target breakpoint number continues to maintain the loop blocking state of the firmware business thread until the variable data is compared with the preset verification conditions and the breakpoint verification result is obtained.

[0090] S3. In response to the breakpoint trigger completion signal, the test platform sends a variable read request. The simulation platform determines the target access address of the variable to be read based on the variable address index table and the memory base address of the storage firmware. While the firmware business thread is in a loop blocking state, the platform directly reads the variable data at the target access address through the memory access path. The reading of variable data does not call the firmware business thread in the loop blocking state. The test platform compares the read variable data with the corresponding preset verification conditions to obtain the breakpoint verification result.

[0091] It should be noted that the test platform saves the current target breakpoint number when sending the target breakpoint trigger command; after receiving the breakpoint trigger completion signal from the simulation platform, the test platform calls the saved current target breakpoint number and calls the corresponding record in the breakpoint information maintenance table according to the current target breakpoint number; the corresponding record in the breakpoint information maintenance table contains the preset breakpoint number as the current target breakpoint number, as well as the name of the variable to be observed, the variable data length, and the preset verification conditions associated with the preset breakpoint number; the test platform extracts the name of the variable to be observed from the corresponding record, determines the name of the variable to be observed as the variable name specified in this variable access process, generates a variable read request carrying the variable name, and then sends the variable read request to the simulation platform; the variable name in the variable read request is consistent with the name of the variable to be observed in the breakpoint information maintenance table, and the name of the variable to be observed in the breakpoint information maintenance table is consistent with the complete variable name in the variable address index table, so that the variable name in the variable read request uniquely corresponds to an index record in the variable address index table; the preset verification conditions are retained in the test platform and participate in the breakpoint verification after the simulation platform returns the variable data.

[0092] The breakpoint trigger completion signal indicates that the stall state flag has been updated from the firmware running state value to the breakpoint stall state value, and that the firmware business thread executing the business node to be verified has entered a loop blocking according to the breakpoint blocking logic. The test platform uses the breakpoint trigger completion signal as the condition for sending variable read requests, and does not send variable read requests if the breakpoint trigger completion signal is not received. After the variable read request is sent, the breakpoint control flag continues to maintain the target breakpoint number, the stall state flag continues to maintain the breakpoint stall state value, and the firmware business thread continues to execute loop blocking within the general breakpoint function, without executing the firmware business process after the business node to be verified.

[0093] The simulation platform receives variable read requests, extracts the name of the variable to be observed from the request, and uses the name of the variable to be observed as a search term to access the variable address index table. Each index record in the variable address index table includes the name of the variable to be observed, the program offset address of the target structure, the offset address of the corresponding member within the structure, and the data length. Following a search rule that variables must be identically named, the simulation platform compares the name of the variable to be observed in the variable read request with the variable names in each index record sequentially, determines the index records with identical variable names, and extracts the program offset address of the target structure to which the variable to be observed belongs, the offset address of the corresponding member within the structure, and the data length from the determined index records.

[0094] The simulation platform obtains the base address of the runtime memory allocated in the simulation platform process address space when the executable image of the storage firmware is running. It then retrieves the variable address index table based on the name of the variable to be observed to obtain the program offset address of the target structure to which the variable to be observed belongs, the offset address of the members in the structure corresponding to the variable to be observed, and the data length.

[0095] Suppose that the base address of the runtime memory of the stored firmware executable image in the process address space of the simulation platform is . The intraprogram offset address of the target structure relative to the starting position of the stored firmware executable image is: Then the first The target access address of each observed variable in the process address space of the simulation platform. for:

[0096] ;

[0097] in, Indicates the first The target access address of each observed variable in the process address space of the simulation platform, in byte address units; This indicates the base address of the running memory in the process address space of the emulation platform when the stored firmware executable image is running, in byte address units.

[0098] The simulation platform will This serves as the starting address for retrieving variable data from the memory access interface.

[0099] The target access address is jointly determined by the base address of the storage firmware's runtime memory, the program offset address of the target structure, and the offset addresses of the members within the structure of the variable to be observed. The data length is limited to a continuous storage range starting from the target access address. The simulation platform uses the target access address as the starting address for variable data acquisition and the corresponding data length in the variable address index table as the variable data acquisition length. The target access address and the data length jointly determine the storage area corresponding to this variable access. When both the target access address and the data length are represented using byte addressing, the first... The final access address of the storage region corresponding to the observed variable can be calculated using the following formula:

[0100] ;

[0101] in, Indicates the first The end access address of the storage area corresponding to the variable to be observed, in byte address units; Indicates the first variable in the variable address index table The data length of the variable to be observed, which takes the value of a positive integer in bytes.

[0102] The test platform determines one or more variables to be observed based on the test script. When the variable read request includes multiple variables to be observed, the simulation platform determines the target access address based on the offset address of the member in the structure corresponding to each variable to be observed. The storage locations of multiple variables to be observed in the target structure do not need to be contiguous. The simulation platform performs memory access according to each target access address and the corresponding data length, and sends the read variable data to the test platform after establishing an association with the corresponding variable name.

[0103] Instead of submitting variable read requests through the storage firmware business input / output path, the simulation platform directly submits the target access address and data length to the simulation platform's memory access interface.

[0104] After determining the target access address, the simulation platform calls the data acquisition function in the memory access interface for the simulation address space. The simulation platform submits the target access address and data length to the data acquisition function. The data acquisition function locates the corresponding storage region in the simulation address space according to the target access address, and extracts consecutive bytes of data corresponding to the data length, starting from the beginning of the storage region and in ascending address order. The data acquisition function extracts consecutive bytes of data sequentially from the target access address to the address range defined by the target access address and the data length, maintaining the order of each byte in the variable data according to ascending address order, and then returns the variable data to the simulation platform's variable access processing procedure. The variable data corresponding to the observed variable can be represented as the following consecutive byte sequence according to the target access address and data length:

[0105] ;

[0106] in, Indicates the first The variable data corresponding to the variable to be observed. Depend on It consists of bytes arranged in ascending order of address; Represents the address in the simulated memory area One byte of data stored in the location; Indicates the first The byte offset of the observed variable relative to the target access address, with a value ranging from 0 to... An integer, in byte address units.

[0107] The variable data represents the data content stored in the storage area corresponding to the target access address at the actual access time while the firmware business thread remains blocked in a loop.

[0108] During variable data acquisition, the firmware business thread continuously retrieves the current value of the breakpoint control flag in the general breakpoint function. The breakpoint control flag retains the target breakpoint number. The firmware business thread does not meet the non-triggering state condition required to exit the loop blocking, therefore the firmware business thread does not execute the firmware code after the business node to be verified. The simulation platform's access to the target access address does not change the breakpoint control flag and the stall state flag. The target breakpoint number continues to maintain the loop blocking condition, and the breakpoint stall state value continues to represent the current stall state of the firmware business thread. Thus, the determination of the target access address, the acquisition of variable data, and the breakpoint verification are all performed during the period when the current firmware business thread remains in a loop blocking state.

[0109] When the memory access interface accesses the target access address, it does not generate business commands for the storage firmware, does not call the command processing function in the storage firmware business input / output path, and does not submit variable read requests to the firmware business thread. The data acquisition function directly locates the simulation storage area corresponding to the target access address based on the address mapping relationship maintained by the simulation platform, and extracts variable data from the simulation storage area. Firmware business threads in a loop-blocked state do not participate in the calculation of the target access address, the location of the simulation storage area, or the extraction of variable data. The state in which the firmware business thread cannot process business input / output requests does not affect the simulation platform from executing this variable access.

[0110] The memory access path, independent of the storage firmware's business input / output path, is formed by the memory access interface in the simulation platform, the address mapping relationship of the simulation address space, and the access relationship between the simulation storage areas. The variable read request sent by the test platform provides the simulation platform with the name of the variable to be observed. The variable address index table and the memory base address of the storage firmware jointly determine the target access address. The target access address and data length are used as access parameters of the memory access interface and are not part of the memory access path. The test platform does not directly operate on the simulation storage area of ​​the storage firmware. The simulation platform locates the simulation storage area corresponding to the target access address through the memory access path and extracts the variable data.

[0111] After acquiring the variable data, the simulation platform establishes a correspondence between the target breakpoint number, the name of the variable to be observed, and the variable data, and then sends the variable data to the test platform. The variable data sent by the simulation platform to the test platform maintains the data length and byte order formed by the data acquisition function. After receiving the variable data, the test platform performs the comparison processing specified by the preset verification conditions according to the same data length and byte order. The test platform calls the corresponding record in the breakpoint information maintenance table according to the current target breakpoint number and extracts the preset verification conditions from the corresponding record. The preset verification conditions are set by the test case for the variable to be observed and include the comparison relationship applied to the variable data and reference data with the same length as the variable data. The reference data arranges each byte in ascending order of the same address as the variable data. The test platform retains the received variable data according to the data length determined by the variable address index table, uses the variable data as the current comparison object, uses the reference data as the benchmark comparison object, and compares them according to the comparison relationship specified by the preset verification conditions.

[0112] 1) When the variable data and the reference data meet the comparison relationship specified by the preset verification conditions, the test platform determines the verification status corresponding to the current target breakpoint as verified as passed, and forms a breakpoint verification result containing the target breakpoint number, the name of the variable to be observed, the variable data and the verification passed status, and incorporates the breakpoint verification result into the subsequent breakpoint control flag clearing process.

[0113] 2) When the variable data and the reference data do not meet the comparison relationship specified by the preset verification conditions, the test platform will determine the verification status corresponding to the current target breakpoint as verification failed, generate a breakpoint verification result containing the target breakpoint number, the name of the variable to be observed, the variable data and the verification failed status, and include the breakpoint verification result in the subsequent breakpoint control flag clearing process.

[0114] Both the pass and fail verification states indicate that the variable data comparison process for the current target breakpoint has been completed. Neither verification state changes the execution path for subsequent breakpoint release. After the test platform generates the breakpoint verification result, the current process generates the target access address, variable data, and breakpoint verification result. The target access address represents the location of the observed variable in the corresponding simulation address space of the current firmware executable image. The variable data represents the data content stored at the location during the firmware business thread's loop blocking period. The breakpoint verification result indicates whether the variable data meets the preset verification conditions. After the breakpoint verification result is generated, the breakpoint control flag continues to retain the target breakpoint number, the stall state flag continues to retain the breakpoint stall state value, and the firmware business thread continues to remain in a loop blocking state. The breakpoint verification result serves as the basis for subsequent clearing of the breakpoint control flag, and does not change the firmware execution state corresponding to the current target breakpoint before the breakpoint control flag is cleared.

[0115] S4. After obtaining the breakpoint verification result, the simulation platform clears the breakpoint control flag through the memory access path. When the storage firmware detects that the breakpoint control flag has been cleared during the loop blocking process, it resets the stall state flag and exits the loop blocking, restoring the scheduling of the firmware business thread.

[0116] It should be noted that the test platform directly uses the already formed breakpoint verification results to determine that the variable data comparison processing of the current target breakpoint has been completed; when the breakpoint verification result is either a verification pass state or a verification fail state, the same breakpoint release process is entered; the test platform sends a breakpoint release request to the simulation platform through the control communication interface used when sending the target breakpoint trigger command. The breakpoint release request corresponds to the current target breakpoint number saved by the test platform and indicates that the variable data acquisition and breakpoint verification of the current target breakpoint have been completed; the test platform saves the breakpoint verification results, and the breakpoint release request does not change the variable data and verification status recorded in the breakpoint verification results.

[0117] During the period from the formation of the breakpoint verification result to the arrival of the breakpoint release request on the simulation platform, the breakpoint control identifier continues to maintain the current target breakpoint number, the stagnation status marker continues to maintain the breakpoint stagnation status value, and the firmware business thread executing the business node to be verified continues to execute a loop blocking in the general breakpoint function; in each loop, the firmware business thread obtains the current identifier value from the mapping address corresponding to the breakpoint control identifier, and does not end the loop blocking until the current identifier value has changed to a non-triggering state value; the test platform's processing of saving the breakpoint verification result does not change the breakpoint control identifier and the stagnation status marker, and the simulation platform does not clear the breakpoint control identifier before receiving the breakpoint release request, thereby maintaining the firmware execution position when the breakpoint verification result is formed.

[0118] After receiving a breakpoint release request, the simulation platform calls the access address of the breakpoint control identifier in the simulation address space from the established shared memory address mapping relationship of the breakpoint control identifier. The access address, data length, and data encoding method of the breakpoint control identifier have been configured in the shared memory address mapping relationship. The non-triggering state value has been determined during the initialization of the breakpoint control identifier and is represented by different values ​​than each preset breakpoint number. The simulation platform converts the non-triggering state value into the corresponding data to be written according to the data length and data encoding method of the breakpoint control identifier, and then submits the access address, data length, and data to be written of the breakpoint control identifier to the data writing function in the memory access interface.

[0119] The data write function locates the corresponding data unit in the shared memory space according to the access address of the breakpoint control identifier, and writes the data to be written, representing the non-trigger state value, into the data unit, thus updating the breakpoint control identifier from the current target breakpoint number to the non-trigger state value. After the breakpoint control identifier is updated, the current target breakpoint number is no longer kept in the breakpoint control identifier, and the control condition required for the firmware business thread to exit the loop blocking is met. The clearing of the breakpoint control identifier is completed when the non-trigger state value is completely written into the corresponding data unit. The shared memory address corresponding to the breakpoint control identifier is not deleted, nor is the address mapping relationship between the breakpoint control identifier and the storage firmware simulation address space changed.

[0120] The simulation platform clears the breakpoint control flag via a memory access path independent of the storage firmware business input / output path. The simulation platform does not generate storage firmware business commands, does not call command processing functions in the storage firmware business input / output path, and does not require firmware business threads in a loop-blocked state to handle breakpoint release requests. The breakpoint control flag access address on the simulation platform side and the breakpoint control flag mapping address on the storage firmware side point to the same data unit in the shared memory space. After the data writing function writes the non-triggering state value to the data unit, the current flag value obtained by the storage firmware from the mapping address corresponding to the breakpoint control flag becomes the non-triggering state value.

[0121] During the loop blocking process, the firmware business thread continuously executes the breakpoint control flag acquisition and non-triggered state judgment, and performs corresponding processing according to the following situations:

[0122] 1) When the current flag value obtained by the firmware business thread has not yet changed to the non-triggering state value, the firmware business thread determines that this acquisition occurred before the non-triggering state value was written, keeps the stalled state marked as the breakpoint stalled state value, and continues to execute the loop blocking; the firmware business thread does not return to the firmware business process after the general breakpoint function, and obtains the current flag value again from the mapping address corresponding to the breakpoint control flag in the next loop; the simulation platform completes a non-triggering state value write through the data write function, and does not repeatedly generate breakpoint release requests;

[0123] 2) When the current flag value obtained by the firmware business thread is equal to the non-triggering state value, the firmware business thread determines that the breakpoint control flag has been cleared, and writes the firmware running state value into the shared memory data unit corresponding to the stagnation state flag according to the data length and data encoding method of the stagnation state flag, so that the stagnation state flag is reset from the breakpoint stagnation state value to the firmware running state value; after the stagnation state flag is reset, the firmware business thread ends the loop blocking, the general breakpoint function completes this call, the program execution position returns to the insertion position of the general breakpoint function in the firmware code, and the firmware business thread continues to be scheduled by the existing thread scheduling mechanism of the storage firmware.

[0124] The current value of the breakpoint control flag is the basis for determining whether the firmware business thread exits the loop blocking. The stagnation flag is not used as a condition for the firmware business thread to exit the loop blocking. The firmware business thread only resets the stagnation flag and ends the loop blocking after obtaining the non-triggering state value, so that the clearing of the breakpoint control flag, the reset of the stagnation flag, and the resumption of the firmware business thread are executed in a determined order. After the stagnation flag is reset, it indicates that the stagnation state of the thread corresponding to the current target breakpoint has been released, and the simulation platform is presented with the state after the firmware business thread resumes operation.

[0125] After the firmware business thread ends its loop blocking, the general breakpoint function completes its call and returns the program control position to the point after the insertion position of the general breakpoint function in the firmware code. Resuming the scheduling of the firmware business thread means removing the restriction imposed by the breakpoint blocking logic on the firmware business thread to continue executing business code, allowing the firmware business thread to continue executing subsequent firmware code from the return position of the general breakpoint function according to the existing thread scheduling mechanism of the stored firmware. The resumption of execution of the firmware business thread does not change the already formed breakpoint verification results, nor does it regenerate the current target breakpoint number.

[0126] After the breakpoint control flag is reset to the non-triggered state value, the current flag value obtained by the general breakpoint function in the firmware code is the non-triggered state value. Since the non-triggered state value is not equal to each preset breakpoint number, the general breakpoint function does not update the stalled state flag and does not control the firmware business thread to re-enter the loop blocking. The firmware business thread continues to run according to the storage firmware business process.

[0127] After the breakpoint is released, the breakpoint control flag remains in a non-triggered state, the stall state flag remains in the firmware running state, the firmware business thread resumes scheduling and continues to execute subsequent firmware code from the return position of the general breakpoint function, and the breakpoint verification result remains in the test platform; the non-triggered state value of the breakpoint control flag indicates that there is currently no effective target breakpoint number, and the firmware running state value of the stall state flag indicates that the thread stall caused by the current target breakpoint has been released.

[0128] In summary, this invention improves the accuracy of breakpoint verification by: setting numbered breakpoints and blocking logic on the service node to be verified, and using a memory access path independent of the storage firmware service input / output path to read variable data during the loop blocking of the firmware service thread; and by automatically linking symbol indexing, breakpoint triggering, stagnation confirmation, variable verification, and breakpoint release, achieving closed-loop execution of the breakpoint debugging and verification process, reducing manual intervention, and improving verification efficiency and result reproducibility.

[0129] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A fully automated breakpoint debugging and verification method for simulation of storage firmware algorithms, characterized in that, include: Compile the storage firmware and establish a variable address index table based on the generated symbol file. Configure preset breakpoint numbers and breakpoint blocking logic on the service nodes to be verified in the storage firmware. Set breakpoint control flags, stall status flags, and memory access paths independent of the service input / output paths of the storage firmware between the simulation platform and the storage firmware. The test platform sends a target breakpoint trigger command to the simulation platform. The simulation platform writes the target breakpoint number into the breakpoint control flag through the memory access path. When the storage firmware executes to the service node to be verified, it compares the read breakpoint control flag with the preset breakpoint number corresponding to the service node to be verified. When the two match, it updates the stagnation status flag and causes the firmware service thread executing the service node to enter a loop blocking. During the loop blocking process, it continuously reads the breakpoint control flag. After the simulation platform detects the update of the stagnation status flag, it sends a breakpoint trigger completion signal back to the test platform. The test platform responds to the breakpoint trigger completion signal by sending a variable read request. The simulation platform determines the target access address of the variable to be read based on the variable address index table and the memory base address of the stored firmware. While the firmware business thread is in a loop blocking state, the platform directly reads the variable data at the target access address through the memory access path. The reading of the variable data does not call the firmware business thread in the loop blocking state. The test platform compares the read variable data with the corresponding preset verification conditions to obtain the breakpoint verification result. After obtaining the breakpoint verification result, the simulation platform clears the breakpoint control flag through the memory access path. When the storage firmware detects that the breakpoint control flag has been cleared during the loop blocking process, it resets the stall state flag and exits the loop blocking, restoring the scheduling of the firmware business thread.

2. The fully automated breakpoint debugging and verification method for storage firmware algorithms as described in claim 1, characterized in that, The process of compiling and storing firmware and establishing a variable address index table based on the generated symbol file includes: During the firmware compilation phase, debug symbol information is preserved, and a symbol file containing firmware variable symbol information is generated. The variable name, the program offset address of the target structure, the offset address of the members in the structure and the data length of each observed variable are analyzed to establish the correspondence and form a variable address index table.

3. The fully automated breakpoint debugging and verification method for storage firmware algorithms as described in claim 1, characterized in that, The configuration of preset breakpoint numbers and breakpoint blocking logic on the service node to be verified in the storage firmware includes: The preset breakpoint numbers corresponding to each service node to be verified are enumerated by macro definition. A general breakpoint function is inserted at the firmware code position corresponding to each service node to be verified, and the corresponding preset breakpoint number is used as the input parameter of the general breakpoint function, so that the firmware code position corresponding to each service node to be verified is associated with the preset breakpoint number. Construct a breakpoint information maintenance table to associate each preset breakpoint number with the corresponding firmware code location, the business module to which it belongs, the name of the variable to be observed, the length of the variable data, and the preset verification conditions; In the general breakpoint function, the breakpoint control flag is read and compared with the preset breakpoint number of the input general breakpoint function. When the two match, the stall state flag is updated and the firmware business thread executing the business node to be verified enters a loop blocking. During the loop blocking process, the breakpoint control flag is continuously read until the breakpoint control flag is detected to have changed to a non-trigger state value. The stored firmware determines that the breakpoint control flag has been cleared and exits the loop blocking.

4. The fully automated breakpoint debugging and verification method for storage firmware algorithms as described in claim 1, characterized in that, The step of setting breakpoint control flags, stall status flags, and memory access paths independent of the storage firmware's business input / output paths between the simulation platform and the storage firmware includes: In the shared memory space accessed by the simulation platform and the storage firmware, the shared memory addresses are configured for the breakpoint control flag and the stall state flag respectively through address mapping. Configure the breakpoint control flag to be written by the simulation platform and read by the storage firmware, and configure the stall state flag to be written by the storage firmware and read by the simulation platform; Configure a memory access interface in the simulation platform so that the simulation platform can access the storage area corresponding to the breakpoint control flag, the stall state flag and the target access address through the memory access interface, without going through the storage firmware business input and output path, thus forming a memory access path independent of the storage firmware business input and output path.

5. The fully automated breakpoint debugging and verification method for storage firmware algorithms as described in claim 1, characterized in that, The simulation platform determines the target access address of the variable to be read based on the variable address index table and the memory base address of the storage firmware, including: Obtain a variable read request sent by the test platform, wherein the variable read request includes the name of the variable to be read; Obtain the base address of the storage firmware's runtime memory; Based on the name of the variable to be read, retrieve the variable address index table to obtain the program offset address of the target structure to which the variable to be read belongs, the offset address of the member in the structure corresponding to the variable to be read, and the data length. The target access address of the variable to be read is obtained by summing the base address of the storage firmware's runtime memory, the program offset address of the target structure, and the offset address of the member in the structure corresponding to the variable to be read.

6. The fully automated breakpoint debugging and verification method for storage firmware algorithms as described in claim 1, characterized in that, The method of directly reading variable data at the target access address through the memory access path while the firmware service thread remains blocked in a loop includes: While the firmware business thread remains blocked in a loop, the simulation platform accesses the storage area corresponding to the target access address through the memory access path. Based on the data length corresponding to the variable to be read in the variable address index table, read the variable data from the target access address and send the read variable data to the test platform; The testing platform compares the read variable data with the corresponding preset verification conditions to obtain the breakpoint verification results.

7. The fully automated breakpoint debugging and verification method for storage firmware algorithms as described in claim 1, characterized in that, The simulation platform clears the breakpoint control flag through the memory access path. When the storage firmware detects that the breakpoint control flag has been cleared during a loop blocking process, it resets the stall state flag and exits the loop blocking, resuming the scheduling of the firmware's business threads, including: After obtaining the breakpoint verification result, the simulation platform writes a non-triggering state value to the breakpoint control flag through the memory access path to clear the breakpoint control flag. The storage firmware continuously reads the breakpoint control flag during the loop blocking process. When it detects that the breakpoint control flag has changed to a non-triggering state value, it determines that the breakpoint control flag has been cleared and resets the stall state flag. The storage firmware exits the loop blocking, resumes the scheduling of the firmware business thread, and continues to execute the business process after the business node to be verified.

8. The fully automated breakpoint debugging and verification method for storage firmware algorithms as described in claim 1, characterized in that, It also includes the breakpoint configuration recovery steps in power failure and restart scenarios: Before performing the power failure and restart test, the simulation platform saves the preset breakpoint number, the information of the variable to be observed, and the preset verification conditions for the business node to be verified, forming breakpoint configuration data. The information of the variable to be observed includes the name of the variable to be observed and the length of the variable data; After the storage firmware restarts and before the storage firmware executes to the corresponding business node to be verified, the simulation platform loads the breakpoint configuration data and writes the preset breakpoint number in the breakpoint configuration data into the breakpoint control identifier through the memory access path. When the storage firmware execution reaches the corresponding business node to be verified, it compares the read breakpoint control flag with the preset breakpoint number corresponding to the business node to be verified. When the two match, it updates the stall state flag and causes the firmware business thread executing the business node to enter a loop blocking state, so as to complete variable data reading and breakpoint verification while the firmware business thread remains in a loop blocking state.

9. The fully automated breakpoint debugging and verification method for storage firmware algorithms as described in claim 1, characterized in that, Also includes: According to the preset test process, multiple business nodes to be verified are determined, and the preset breakpoint numbers corresponding to each business node to be verified are obtained in sequence. For each business node to be verified, the test platform sends the corresponding target breakpoint trigger command to the simulation platform in sequence. The simulation platform executes the operations of writing the target breakpoint number into the breakpoint control identifier, detecting the stall state marker, reading variable data through the memory access path, and clearing the breakpoint control identifier in sequence. The test platform compares the read variable data with the corresponding preset verification conditions in sequence to obtain the breakpoint verification result for each business node to be verified. The breakpoint triggering information, variable access information, and breakpoint verification results for each business node to be verified are summarized to generate a firmware algorithm verification report.

10. The fully automated breakpoint debugging and verification method for storage firmware algorithms as described in claim 5, characterized in that, It also includes a variable modification verification step: While the firmware business thread remains blocked in a loop, the test platform determines the variable to be modified and the corresponding target variable value according to the preset test scenario, and sends a variable modification request including the name of the variable to be modified and the target variable value to the simulation platform. The simulation platform determines the target access address of the variable to be modified based on the variable address index table and the memory base address of the stored firmware, and writes the target variable value to the target access address of the variable to be modified through the memory access path. The writing of the target variable value does not call the firmware business thread that is in a loop blocking state. After writing the target variable value, the simulation platform clears the breakpoint control flag through the memory access path. When the storage firmware detects that the breakpoint control flag has been cleared during the loop blocking process, it resets the stall state flag and exits the loop blocking, restores the scheduling of the firmware business thread, and continues to execute the corresponding business process according to the written target variable value. The test platform sends the target breakpoint trigger command corresponding to the subsequent service node to be verified to the simulation platform. The simulation platform writes the target breakpoint number corresponding to the subsequent service node to be verified into the breakpoint control flag through the memory access path, so that the storage firmware enters a loop blocking when it executes to the subsequent service node to be verified. During the period when the firmware business thread remains blocked in a loop, the simulation platform determines the target access address of the variable to be read corresponding to the business node to be verified according to the variable address index table and the memory base address of the stored firmware, and directly reads the variable data at the target access address through the memory access path. The test platform compares the read variable data with the corresponding preset verification conditions to obtain the breakpoint verification result, so as to verify the firmware algorithm execution status after writing the target variable value.

Images