Method for testing registers and storage device
By using pre-built files and dynamic addressing mechanisms to parse register data in UFS devices, the problems of frequent code modifications and difficulties in porting multiple projects in register verification methods are solved, achieving efficient and flexible register testing.
Patent Information
- Application Number
- CN202511014648.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-23
- Publication Date
- 2025-11-25
- Estimated Expiration
- 2045-07-23
AI Technical Summary
Existing register verification methods for UFS device testing suffer from problems such as frequent code modifications and difficulties in code porting between multiple projects, resulting in low testing efficiency and a heavy workload for developers.
By storing the standard data of the registers in a pre-configured file and employing dynamic addressing and identifier matching mechanisms, the registers are structured and iteratively verified, avoiding hard coding and supporting rapid portability between different projects.
It improves the efficiency and flexibility of register verification, reduces code maintenance work, and supports rapid adaptation between different projects and the integrity of test results.
Smart Images

Figure CN120544645B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of storage device testing, and in particular to a method for testing a register and a storage device. BACKGROUND
[0002] In the current UFS (Universal Flash Storage) protocol test, the register verification test is used to detect whether the initial value of the register of the UFS device after the card is opened (including descriptors, attributes, flags, etc.) is completely consistent with the value specified in the product specification. The existing register verification method is implemented by defining two arrays size_len and verify_vals, wherein the array size_len is used to describe the size of the register field and whether to check, and the array verify_vals is used to store the value specified in the specification. During testing, the register value is read and compared with the array content to complete the check.
[0003] However, the existing register verification method has many deficiencies, which are as follows:
[0004] During the entire product testing cycle, the product specification may be modified and aligned multiple times. Since the check values are directly written in the arrays in the code, the test developer needs to frequently modify the test case and re-release. In addition, the check value information is stored in multiple arrays, such as the size of the field, whether to check, and the specific content of the value. This makes it necessary to modify multiple contents at the same time when modifying the code, and careful alignment is required to ensure that the modification is correct. After modification, the code needs to be recompiled to generate an image, and local verification needs to be performed. This series of operations is not only tedious, but also prone to errors, which greatly wastes the time and effort of the test developer.
[0005] Among different UFS projects, the standards of the product, the version of the UFS protocol used, and the supported functions may differ significantly, which leads to differences in the register values of the UFS device. Therefore, when a new UFS project needs to be tested, a large amount of modification needs to be made to the existing code to realign the contents of the size_len and verify_vals arrays. In this case, the code of other projects cannot be directly reused, which leads to the need for a large amount of human resources for code transplantation and modification when multiple UFS projects exist at the same time.
[0006] In summary, the existing array-based register verification method has problems such as repeated modification of the code and difficulty in code transplantation between multiple projects. These problems not only reduce the test efficiency, but also increase the workload of the test developer, seriously affecting the test progress and quality of the UFS product. SUMMARY
[0007] The technical problem solved by the present application is to provide a method for testing a register and a storage device, which can effectively improve the efficiency and flexibility of register checking.
[0008] To solve the above technical problem, one technical solution adopted by the present application is:
[0009] A method for testing a register, comprising:
[0010] loading standard data of all registers in a preset file into a target storage space;
[0011] determining a storage position of target standard data of a to-be-tested register in the target storage space;
[0012] acquiring standard field data in the target standard data based on the storage position;
[0013] reading a to-be-tested initial value of the to-be-tested register corresponding to the standard field data according to a type of the to-be-tested register;
[0014] after checking the to-be-tested initial value according to the standard field data to obtain a checking result, returning to acquire the standard field data in the target standard data based on the storage position until the target standard data is checked and tested completely;
[0015] generating a test result of the to-be-tested register according to the checking result.
[0016] To solve the above technical problem, another technical solution adopted by the present application is:
[0017] A storage device, comprising a storage chip and a control chip, the storage chip storing a computer program, the computer program being executed by the control chip to realize each step in the above method for testing a register.
[0018] The beneficial effects of the present application are as follows: firstly, the standard data of all registers is loaded to the storage space as a whole through the preset file, so that the standard data for checking the initial value of the register is independent of the test program, avoiding the defect that the standard value is hard-coded in the program array in the traditional method. A dynamic addressing mechanism is used when determining the storage location, and the standard data storage location of the register to be tested is obtained by analyzing the target storage space. This dynamic positioning method based on the content of the file can adapt to the differences in the standard data structure of different projects. When obtaining the field data, the standard field data is extracted according to the storage location, the structured analysis of the multiple field data of the register is realized, and then the standard field data in the target standard data is verified item by item through the loop checking mechanism until the test of all fields is completed. This iterative checking method can automatically cover all parameter items of the register that need to be detected. Finally, the test result is generated based on the checking result, forming a complete test closed loop. The whole scheme combines the preset file with dynamic analysis, so that the standard data can be independently maintained and updated without modifying the test program code, while supporting the rapid transplantation between different projects, effectively improving the efficiency and flexibility of the register checking. BRIEF DESCRIPTION OF DRAWINGS
[0019] Fig. 1 A flowchart of a method for testing a register provided by an embodiment of the present application is provided.
[0020] Fig. 2 Another flowchart of a method for testing a register provided by an embodiment of the present application is provided.
[0021] Fig. 3 A structural schematic diagram of a storage device provided by an embodiment of the present application is provided. DETAILED DESCRIPTION
[0022] To explain the technical content, the achieved purposes and effects of the present application in detail, the following will be explained in combination with the embodiments and the drawings.
[0023] The embodiments of the present application provide a method for testing a register, comprising:
[0024] loading the standard data of all registers in the preset file to a target storage space;
[0025] determining the storage location of the target standard data of the register to be tested in the target storage space;
[0026] obtaining the standard field data in the target standard data based on the storage location;
[0027] reading the initial value to be tested of the register to be tested corresponding to the standard field data according to the type of the register to be tested;
[0028] After the checking result of the initial value to be tested is obtained by checking the standard field data in the target standard data according to the standard field data, the method returns to the step of obtaining the standard field data in the target standard data based on the storage location until the target standard data is completely checked.
[0029] The test result of the register to be tested is generated according to the checking result.
[0030] As can be seen from the above description, the beneficial effects of the present application are as follows: first, the standard data of all registers is loaded to the storage space as a whole through the preset file, so that the standard data for checking the initial value of the register is independent of the test program, avoiding the defect that the standard value is hard-coded in the program array in the traditional method. When the storage location is determined, the dynamic addressing mechanism is adopted to obtain the storage location of the standard data of the register to be tested by analyzing the target storage space. This dynamic positioning method based on the content of the file can adapt to the differences in the standard data structure of different projects. When the field data is obtained, the standard field data is extracted according to the storage location, the structured analysis of the multiple field data of the register is realized, and then the standard field data in the target standard data is verified item by item through the loop checking mechanism until the complete field test is completed. This iterative checking method can automatically cover all parameter items of the register that need to be detected. Finally, the test result is generated based on the checking result, forming a complete test closed loop. The whole scheme combines the preset file with dynamic analysis, so that the standard data can be independently maintained and updated without modifying the test program code, while supporting the rapid transplantation between different projects, effectively improving the efficiency and flexibility of the register checking.
[0031] Further, loading the standard data of all registers in the preset file to the target storage space includes:
[0032] Constructing a data loading function based on the storage address of the preset file in the storage device;
[0033] Loading the standard data of all registers to the target storage space through the data loading function.
[0034] As can be seen from the above description, the data loading function is constructed based on the storage address of the preset file in the storage device, so that the standard data can be stored separately from the test code. When the product specification changes, only the preset file needs to be updated without modifying the test program. The standard data is loaded to the target storage space through the data loading function. This loading method not only eliminates the coupling of the standard data and the code, but also realizes the effect that only the preset file needs to be replaced when cross-project testing is performed.
[0035] Further, determining the storage location of the target standard data of the register to be tested in the target storage space includes:
[0036] An object identifier of the to-be-tested register is acquired, and a storage location of target standard data matching the object identifier in the target storage space is determined.
[0037] As can be seen from the above description, the feature of acquiring the object identifier of the to-be-tested register abstracts the register identity information into an identifier that can be independently identified, thereby getting rid of the limitation of relying on fixed array index or hard-coded address in the traditional method. By matching the object identifier with the data in the target storage space, the standard data of the corresponding register can be directly extracted from the preloaded standard data set, avoiding the operation of manually modifying the storage location definition in the code due to the change of the specification. The matching mechanism of the object identifier establishes a logical association rather than a physical address binding, so that the register data of different projects or different versions can be reused across projects by maintaining a unified identifier system, thereby fundamentally solving the problem of repeatedly adjusting the storage location in the traditional method.
[0038] Further, the acquiring of the standard field data in the target standard data based on the storage location comprises:
[0039] Acquiring sub-data in the target standard data based on the storage location, and storing the sub-data to a first data structure according to a position state of the sub-data to obtain the standard field data.
[0040] As can be seen from the above description, the acquiring of the sub-data in the target standard data based on the storage location can accurately locate the standard data segment of the to-be-tested register, avoiding manual searching and code hard coding. The sub-data is stored to the first data structure according to the position state, and the discrete sub-data is reorganized into structured data according to the logical relationship. This dynamic storage mechanism based on the position state can not only adapt to the differences in register fields in different protocol versions or projects, improving the portability and reusability of the test case, but also realize the unified management of the standard field data through the first data structure, providing a directly callable data object for subsequent automatic verification.
[0041] Further, the determining of the storage location of the target standard data matching the object identifier in the target storage space comprises:
[0042] Traversing the storage data at each offset address in the target storage space;
[0043] If the traversed storage data does not belong to the preset invalid character data, storing the storage data to a first temporary array to obtain valid character data;
[0044] Comparing the valid character data with the object identifier;
[0045] If the comparison is consistent, the offset address of the valid character data is stored to a preset standard address array to obtain a storage location of the target standard data.
[0046] If the comparison is inconsistent, the valid character data in the first temporary array is cleared, and the storage data at a next offset address in the target storage space is continuously traversed.
[0047] As can be seen from the above description, the storage data at each offset address in the target storage space is traversed to ensure that all possible storage locations are covered and missed. The traversed storage data is filtered by the preset invalid character data, only the valid character data is retained and stored in the temporary array, thereby excluding invalid data and improving the accuracy of data processing. The valid character data is compared with the target identifier to accurately lock the position of the target standard data through the identifier matching mechanism, and manual intervention is reduced. When the comparison is consistent, the offset address of the valid character data is stored in the standard address array to provide a directly referenced storage location information for subsequent verification. Through the synergistic effect of dynamic traversal, invalid data filtering and intelligent matching, the scheme solves the problem of difficult code maintenance caused by the dependence of the traditional method on hard-coded addresses, and significantly improves the generality and cross-project reuse ability of test cases.
[0048] Further, based on the storage location, sub-data in the target standard data is obtained, and the sub-data is stored in a first data structure according to a position state of the sub-data to obtain standard field data, including:
[0049] Traversing the target storage data at the storage location in the target storage space;
[0050] If the traversed target storage data does not belong to the preset invalid character data, the target storage data is stored in a second temporary array to obtain different sub-data in the target standard data;
[0051] According to the position state of the traversal, the data attribute of the sub-data is determined, and the sub-data is converted and stored in the first data structure according to the data attribute to obtain the standard field data.
[0052] As can be seen from the above description, traversing the data at the storage location can ensure that the target standard data of the to-be-tested register is directly obtained in the target storage space, avoiding data acquisition errors while improving data acquisition efficiency. Through the filtering mechanism of the preset invalid character data, non-valid information such as spaces and separators can be automatically excluded, ensuring that the extracted sub-data is valid field content. Different sub-data is classified and stored in the second temporary array according to the traversal position state, which can preserve the physical storage order of the original data and provide context basis for subsequent attribute recognition.
[0053] Further, the data attribute includes offset data, length data, name character and numerical data;
[0054] The sub-data is respectively converted according to the data attribute and then stored in a first data structure to obtain standard field data, including:
[0055] The sub-data with the data attribute of offset data is converted into a first binary through a string conversion function and then stored in a first variable;
[0056] The sub-data with the data attribute of length data is converted into a second binary through the string conversion function and then stored in a second variable;
[0057] The sub-data with the data attribute of name character is copied to a third variable through a copy function;
[0058] The sub-data with the data attribute of numerical data is converted into the first binary through the string conversion function and then stored in a fourth variable;
[0059] A first data structure is constructed according to the first variable, the second variable, the third variable and the fourth variable to obtain standard field data.
[0060] From the above description, for offset data, a string conversion function is used to convert it into a first binary and store it in a first variable, ensuring that the subsequent address calculation can directly use numerical type data; for length data, it is also converted into a second binary through a string conversion and stored in a second variable, so as to distinguish it from offset data and avoid confusion; for name character, the original string attribute is directly preserved through a copy function to maintain the readability of the field; for numerical data, it is converted into a first binary and stored in a fourth variable to ensure that the numerical comparison format is consistent. Finally, the four variables are integrated to construct a first data structure, which unifies the originally scattered field attributes into a structured object, so that the calling and checking process of standard field data can be directly based on the structure members, avoiding manual alignment of multiple independent arrays, and improving the reusability of data structures between different projects.
[0061] Further, according to the type of the to-be-tested register, a to-be-tested initial value corresponding to the to-be-tested register and the standard field data is read, including:
[0062] According to the type of the to-be-tested register, a corresponding reading instruction is called to read to-be-tested field data of the to-be-tested register and store it in a target buffer space;
[0063] According to the first variable and the second variable, a to-be-tested initial value in the to-be-tested field data is read from the target buffer space.
[0064] From the above description, first, according to the type of the to-be-tested register, the corresponding read instruction is called, which solves the data reading compatibility problem caused by the difference of different register access protocols. Secondly, the to-be-tested field data read is stored in the target buffer space, and a unified data processing intermediate layer is constructed, which provides a structured data basis for subsequent verification. Finally, based on the first variable (offset data) and the second variable (length data), the to-be-tested initial value is extracted from the buffer space, and the data extraction process is driven by standardized parameters, so that the verification process does not need to pay attention to the details of the physical storage structure of the register, and only depends on the pre-defined standard field parameters to complete the accurate data positioning and cutting. This parameterized configuration-based reading method effectively solves the code modification problem caused by the change of register specifications during multi-project testing, and improves the scalability of the test framework.
[0065] Further, reading the to-be-tested initial value in the to-be-tested field data from the target buffer space according to the first variable and the second variable comprises:
[0066] reading the to-be-tested field data with a size of the second variable from the target buffer space with the first variable as a starting address to obtain the to-be-tested initial value.
[0067] From the above description, based on the combination of the first variable (starting address) and the second variable (data length), the corresponding to-be-tested field data is extracted from the target buffer space. Among them, the first variable serves as the reference of the starting address, which ensures that the data reading position strictly corresponds to the offset of the standard field data, avoiding the problem of strong coupling between code and product project caused by fixed address in traditional methods; the second variable serves as the basis for data length, and through dynamic setting of the reading range, it can adapt to the bit width difference of different register fields. This two-dimensional control mechanism based on variable parameters makes the test program not need to be hard-coded for the address and length of each register, fundamentally solving the problem of repeated code modification due to the change of register specifications during multi-project testing, and improving the compatibility of the test program for different protocol versions and function configurations.
[0068] Further, verifying the to-be-tested initial value according to the standard field data to obtain a verification result comprises:
[0069] comparing whether the fourth variable and the to-be-tested initial value are consistent;
[0070] if consistent, it is determined that the to-be-tested initial value corresponding to the standard field data passes the verification;
[0071] if inconsistent, it is determined that the to-be-tested initial value corresponding to the standard field data fails the verification;
[0072] generating a test result of the to-be-tested register according to the verification result comprises:
[0073] generating a test result of the to-be-tested register according to a check result of all standard field data in the target standard data.
[0074] As can be seen from the above description, by directly comparing the numerical data (fourth variable) in the standard field data with the to-be-tested initial numerical value, an atomized check unit is formed, and this comparison method based on variable mapping can adapt to different numerical formats of different register types. In the test result generation stage, by aggregating the check states of all standard fields, a comprehensive result reflecting the overall test state of the register is constructed. This layered check and result integration mechanism enables the test system to automatically adapt to different register structures, and there is no need to separately write check logic for each register, thereby fundamentally solving the problem of strong coupling between check logic and register structure in the traditional method.
[0075] Further, before loading the standard data of all registers in the preset file to the target storage space, the method further comprises:
[0076] storing the preset file into the non-volatile storage address of the storage device through a serial loading function.
[0077] As can be seen from the above description, the preset file is stored into the non-volatile storage address of the storage device through the serial loading function, so that the data is ensured not to be lost after power failure, and the data persistence is improved. Through the serial loading mode, the preset file can be conveniently transmitted to different test platforms, and the flexibility and universality of the method are enhanced.
[0078] Another embodiment of the present application provides a storage device comprising a storage chip and a control chip, wherein the storage chip stores a computer program, and the computer program is executed by the control chip to realize each step in the above method for testing a register.
[0079] The method and storage device for testing the register can be applied to a UFS (Universal Flash Storage) protocol test process. A prior register verification method is implemented by defining two arrays, size_len and verify_vals, in code. The size_len array is used to describe the size of each field of the register and whether the field needs to be checked. For example, {1, 1} indicates that the field is 1 byte in size and needs to be checked; {4, 0} indicates that the field is 4 bytes in size but does not need to be checked. The verify_vals array is used to store the values that need to be checked, i.e., the values specified in the product specification. During the test process, the values of the register are read and stored in a buffer, then the values are checked according to the arrays, and the checking results are printed, thereby completing the test. However, this register verification method has problems such as the need to repeatedly modify the code and the difficulty of code transplantation between multiple projects. Therefore, the present application provides a method for testing a register, which can effectively improve the efficiency and flexibility of register verification, and the following is described through a specific embodiment:
[0080] Please refer to Figs. 1-2 Embodiment one of the present application is:
[0081] A method for testing a register includes the following S0-S5:
[0082] S0, a preset file is stored in a non-volatile storage address of a storage device by a serial port loading function.
[0083] Specifically, the preset file stores standard data of all registers, and the standard data refers to values specified in a product specification.
[0084] In some embodiments, the standard data of different registers in the preset file is distinguished by an empty line, i.e. there is a line break between the standard data of different registers, and the ASCII code of the line break is 0Dh 0Ah. The standard data of each register includes a self-defined unique identifier and a plurality of different field data. The unique identifier of each register in the preset file is set in the first line, and each line after the unique identifier represents a field data. The data structure of each field data is: [offset] [byte size] [field name] [value1 / value2 / value3], wherein the values of some field data are different under different capacity products, and therefore [value1 / value2 / value3] represents the values corresponding to different capacity products under the same UFS item, and the values are separated by " / ". For example, the field data qTotalRawDeviceCapacity represents the total capacity of the grain. Therefore, the total capacity of the 64G grain product is 7734000h, and the total capacity of the 128G grain product is EE64000h. Thus, the data structure in the preset file is shown in Table 1:
[0085] Table 1: Data structure of the preset file
[0086]
[0087] After storing the standard data of all registers according to the above data structure in the preset file, the preset file on the PC side is transmitted to the non-volatile address of the storage device eMMC specified by the macro definition RC_1_ADDR through the serial port by using the serial port loading function do_load_serial_rc(). The command loadx_rc can be issued in the serial port tool to start the above file transmission process, so as to save the preset file in the test platform without loss of power failure. In this way, without modifying the standard data of the registers, only one transmission of file data is required, and the register verification test can be performed on multiple versions of products.
[0088] S1, load the standard data of all registers in the preset file to the target storage space.
[0089] Specifically, S1 includes:
[0090] S11, construct a data loading function based on the storage address of the preset file in the storage device.
[0091] S12, load the standard data of all registers to the target storage space by using the data loading function.
[0092] The target storage space is a memory space applied for. Since the preset file is previously saved in the eMMC through the communication protocol, the data is still saved well even if the platform is powered off. When the initial value of the register is checked, the data needs to be obtained from the eMMC, at which time a memory space is applied for and an eMMC read command is sent to read the data into the memory space.
[0093] In some embodiments, if the storage address of the preset file in the storage device is RC_1_ADDR and the target storage space is rc_buf, the data loading function is specifically bw_emmc_read_buf(RC_1_ADDR, (RC_SIZE+511) / 512, 0, rc_buf), and the function of the function is specifically: transmitting the data of the storage device eMMC starting from the RC_1_ADDR address to the rc_buf memory space, and the size of the data to be transmitted is RC_SIZE. RC_SIZE can be set to 1MB (sufficient to accommodate all register information), and the memory space size of rc_buf is RC_SIZE*sizeof(u8).
[0094] S2, determining the storage position of the target standard data of the to-be-tested register in the target storage space.
[0095] Specifically, S2 includes:
[0096] S21, obtaining the target identifier of the to-be-tested register, and determining the storage position of the target standard data matched with the target identifier in the target storage space.
[0097] In some embodiments, the target identifier of the to-be-tested register is stored in a key_word character array.
[0098] In S21, determining the storage position of the target standard data matched with the target identifier in the target storage space includes S211-S215:
[0099] S211, traversing the storage data at each offset address in the target storage space.
[0100] S212, if the traversed storage data does not belong to the preset invalid character data, storing the storage data into a first temporary array to obtain valid character data.
[0101] S213, comparing the valid character data with the target identifier, if the comparison is consistent, performing S214, and if the comparison is inconsistent, performing S215.
[0102] S214, store the offset address of the valid character data to a preset standard address array to obtain a storage location of the target standard data;
[0103] S215, clear the valid character data in the first temporary array and continue to traverse storage data at a next offset address in the target storage space.
[0104] In some embodiments, S211-S215 are encapsulated in a function get_desc_base_addr, and the storage location of the target standard data in the target storage space can be determined by calling the function get_desc_base_addr.
[0105] The above S211-S215 are applied to a specific scenario, specifically: initializing a variable base_addr as 0. Starting to traverse rc_buf from an offset cur_addr=0, if the data at rc_buf[cur_addr] is not equal to a space (20h), a tab (09h), or a line feed (0Dh 0Ah), the data is stored in a temp character array. Comparing the contents of a key_word character array and the temp character array; if they are equal, it indicates that the target standard data of the to-be-tested register is successfully located, and base_addr=cur_addr+2 (i.e., skipping the line feed after the identifier) is assigned to obtain the storage location of the target standard data; if they are not equal, it indicates that the target standard data of the to-be-tested register is not located, the data in the temp character array is cleared, and the traversal is continued until the traversal of the target storage space is completed.
[0106] S3, obtaining standard field data in the target standard data based on the storage location.
[0107] Specifically, S3 includes:
[0108] S31, obtaining sub-data in the target standard data based on the storage location, and storing the sub-data to a first data structure according to a position state of the sub-data to obtain standard field data.
[0109] S31 includes S311-S313.
[0110] S311, traversing target storage data at the storage location in the target storage space.
[0111] S312, if the traversed target storage data does not belong to preset invalid character data, storing the target storage data to a second temporary array to obtain different sub-data in the target standard data.
[0112] S313、According to the position state of traversal, the data attribute of the sub-data is determined, and the sub-data is respectively converted and stored into the first data structure in sequence to obtain the standard field data according to the data attribute.
[0113] In some embodiments, the position state variable cur_state is initialized as 1, and the target storage space rc_buf is traversed from the storage position base_addr. If the data at rc_buf[base_addr] is not equal to space (20h), Tab (09h), or line feed (0Dh 0Ah), the data is stored in the temp character array to obtain the sub-data, and the position state variable cur_state is updated by incrementing. When the position state variable cur_state is greater than 4, it is reset to 1. Specifically, since the data structure of each field data is: [offset] [byte size] [field name] [value1 / value2 / value3], when cur_state is 1, it means that the sub-data stored in the temp character array is the offset; when cur_state is 2, it means that the sub-data stored in the temp character array is the byte size; when cur_state is 3, it means that the sub-data stored in the temp character array is the field name; and when cur_state is 4, it means that the sub-data stored in the temp character array is value1 / value2 / value3.
[0114] Specifically, the data attribute includes offset data, length data, name character, and value data. Therefore, the offset data, length data, name character, and value data in the data attribute correspond to [offset], [byte size], [field name], and [value1 / value2 / value3] in the field data structure, respectively.
[0115] In S313, according to the data attribute, the sub-data is respectively converted and stored into the first data structure in sequence to obtain the standard field data, including S3131-S3135:
[0116] S3131, the sub-data with the data attribute of offset data is converted into the first binary through the string conversion function and stored into the first variable.
[0117] S3132, the sub-data with the data attribute of length data is converted into the second binary through the string conversion function and stored into the second variable.
[0118] S3133, the sub-data with the data attribute of name character is copied to the third variable through the copy function.
[0119] S3134, the sub-data with the data attribute of value data is converted into the first binary through the string conversion function and stored into the fourth variable.
[0120] S3135, constructing a first data structure according to the first variable, the second variable, the third variable and the fourth variable to obtain standard field data.
[0121] In some embodiments, a first data structure descinfo is defined to store the standard field data. When the sub-data stored in the temp character array is an offset, it is converted to hexadecimal by a string conversion function strtoul and stored in a predefined first variable descinfo.info_offset. When the sub-data stored in the temp character array is a byte size, it is converted to decimal by a string conversion function strtoul and stored in a predefined second variable descinfo.info_size. When the sub-data stored in the temp character array is a field name, it is copied to a predefined third variable descinfo.info_name by a copy function memcpy. When the sub-data stored in the temp character array is a value 1 / value 2 / value 3, it is converted to hexadecimal by a string conversion function strtoul and stored in a predefined fourth variable descinfo.info_value. Since the " / " character will be traversed in the value, the position state variable cur_state is still set to 4 when the " / " character is traversed, and is set to 1 after all values are obtained.
[0122] In some embodiments, before S311, a detection variable check_flag is initialized to 0, and the detection variable check_flag is used to indicate whether the current field data is checked. Specifically, when the position state variable cur_state is set from 4 to 1, the detection variable check_flag is also set to 1 at the same time; after the offset data is stored in the first variable, the detection variable check_flag is also reset to 0 at the same time. When the detection variable check_flag is set to 1, S4 is executed.
[0123] S4, reading a to-be-tested initial value corresponding to the to-be-tested register and the standard field data according to the type of the to-be-tested register.
[0124] Specifically, S4 includes:
[0125] S41, respectively invoking corresponding read instructions according to the type of the to-be-tested register to read the to-be-tested field data of the to-be-tested register and store it to a target buffer space.
[0126] In some embodiments, a SCSI Command command is sent to read the initial values of the to-be-tested registers of the UFS device into a target buffer space desc_buf. According to different types of registers, different operations need to be performed, as follows: for the descriptor register, a read command QUERY REQUEST is called, at which time the read command can read all field data of the specified descriptor register at one time, so this step S41 needs to be performed only once for the descriptor register. For the MODE PAGE / VPD PAGE register, a read command ModeSense10 / INQUIRY is called, at which time the read command can read all field data of the specified PAGE at one time, so this step S41 also needs to be performed only once for the MODE PAGE / VPD PAGE register. For the flag / attribute register, a read command QUERY REQUEST is called, but at this time only one field data can be read at one time, so after each execution of step 41, the flag / attribute of the field data needs to be read according to the offset specified by the first variable descinfo.info_offset.
[0127] S42, reading the initial values of the to-be-tested field data from the target buffer space according to the first variable and the second variable.
[0128] In some embodiments, S42 includes reading the to-be-tested field data of the size of the second variable from the target buffer space with the first variable as the starting address, to obtain the initial values of the to-be-tested field data.
[0129] In some embodiments, an address index index in the target buffer space is defined, which is used to indicate the position of the to-be-tested field data in the target buffer space desc_buf. If the obtained register is a descriptor, a MODE PAGE, or a VPD PAGE, then according to the offset indicated by the first variable descinfo.info_offset, the specified field data in the target buffer space desc_buf is located, i.e., index = descinfo.info_offset. If the obtained register is an attribute / flag, then the starting address of the target buffer space desc_buf stores the to-be-tested field data, i.e., index = 0.
[0130] According to the address index index and the second variable descinfo.info_size, the initial value of the to-be-tested desc_buf is stored in the predefined to-be-tested array desc_value. Starting from the address index index, one byte of data is read each time. Since the data is stored in a big-endian mode (the high bits of the data are stored in the low address space, and the low bits are stored in the high address space), the data is shifted according to index and descinfo.info_size, and then added to the predefined desc_value. Then, the index index is incremented to read the next byte of data. A total of descinfo.info_size bytes of data are read. After completion, the desc_value stores the initial value of the to-be-tested data of the specified field.
[0131] S5, after the initial value of the to-be-tested is verified according to the standard field data to obtain a verification result, returning to execute S3 until the target standard data completes the verification test.
[0132] S6, according to the verification result, generating a test result of the to-be-tested register.
[0133] Specifically, in S5, according to the standard field data to verify the initial value of the to-be-tested to obtain a verification result, including: comparing the fourth variable with the initial value of the to-be-tested, if consistent, it is determined that the initial value of the to-be-tested corresponding to the standard field data passes the verification; if not consistent, it is determined that the initial value of the to-be-tested corresponding to the standard field data fails the verification.
[0134] In some embodiments, comparing the fourth variable with the initial value of the to-be-tested is specifically: comparing the to-be-tested array desc_value with the fourth variable descinfo.info_value, if the comparison is consistent, the initial value of the to-be-tested of the next field data is obtained; if the comparison is inconsistent, an error message is printed, the verification result result_flag is set to 1, and the initial value of the to-be-tested of the next field data is obtained.
[0135] Specifically, S6 includes: according to the verification results of all standard field data in the target standard data, generating a test result of the to-be-tested register.
[0136] In some embodiments, after completing the verification test of all field data in the to-be-tested register, the test result is judged according to the verification result result_flag: if the verification result result_flag is "1", it indicates that the test fails; if the verification result result_flag is "0", it indicates that the test passes.
[0137] Referring to Fig. 3 Embodiment two of the present application is:
[0138] A storage device includes a storage chip and a control chip, the storage chip stores a computer program, and the computer program is executed by the control chip to realize each step in the method for testing the register of embodiment one.
[0139] In summary, the present application provides a method for testing a register and a storage device, by storing register standard data in a separate preset file and using a dynamic loading and parsing mechanism, the defects of hard coding standard values in the program in the traditional method are avoided, independent maintenance and updating of standard data are realized, the test program code does not need to be modified, and cross-project transplantation is facilitated. When determining the storage location, a dynamic addressing and identifier matching mechanism is used, which can adapt to the differences in standard data structures of different projects, and solves the code maintenance difficulty problem caused by the dependence on fixed addresses in the traditional method. When obtaining field data, through a dynamic storage mechanism based on position state, discrete sub-data is reorganized into structured data, improving the portability and reusability of test cases. In addition, through a loop verification mechanism, the register field data is verified item by item, all detection parameter items are automatically covered, and a complete test closed loop is formed. The whole scheme not only improves the efficiency and flexibility of register verification, but also enhances the universality and flexibility of the test method through the serial port loading function, and is suitable for various test platforms and project requirements.
[0140] In the above embodiments provided in the present application, it should be understood that the disclosed method, device, computer readable storage medium and electronic device can be implemented in other ways. For example, the above-described device embodiments are only schematic, for example, the division of the modules is only a logical function division, and actual implementation can have another division manner, for example, a plurality of components or modules can be combined or integrated into another device, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed components can be indirect coupling or communication connection through some interfaces, devices or components or modules, and can be electrical, mechanical or other forms.
[0141] The components described as separate components can or can not be physically separate, and the components shown as components can or can not be physical modules, that is, they can be located in one place, or can be distributed on multiple network modules. According to actual needs, part or all of the components can be selected to achieve the purpose of the present embodiment scheme.
[0142] In addition, each function module in each embodiment of the present application can be integrated in one processing module, or each component can be physically present separately, or two or more modules can be integrated in one module. The integrated module can be realized in the form of hardware or in the form of a software function module.
[0143] When the integrated module is realized in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the present application or the whole or part of the technical solutions that essentially contribute to the prior art can be embodied in the form of a software product, which is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various program code storage media.
[0144] It should be noted that, for each method embodiment described above, in order to simplify the description, each method embodiment is described as a combination of a series of actions, but those skilled in the art should know that the present application is not limited by the described action sequence, because according to the present application, certain steps can be performed in other order or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification all belong to preferred embodiments, and the actions and modules involved are not necessarily essential to the present application.
[0145] In the above embodiments, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.
[0146] The above is only an embodiment of the present application, and does not limit the patent scope of the present application, and any equivalent transformation or direct or indirect application in related technical fields based on the content of the specification and drawings of the present application is also included in the patent protection scope of the present application.
Claims
1. A method for testing a register, characterized by, The method comprises the following steps: loading standard data of all registers in a preset file into a target storage space; determining a storage location of target standard data of a to-be-tested register in the target storage space; acquiring standard field data in the target standard data based on the storage location; reading a to-be-tested initial value of the to-be-tested register corresponding to the standard field data according to a type of the to-be-tested register; after checking the to-be-tested initial value according to the standard field data to obtain a checking result, returning to acquire the standard field data in the target standard data based on the storage location until the target standard data is checked and tested completely; generating a test result of the to-be-tested register according to the checking result; loading the standard data of all registers in the preset file into the target storage space comprises the following steps: constructing a data loading function based on a storage address of the preset file in a storage device; loading the standard data of all registers into the target storage space through the data loading function; determining the storage location of the target standard data of the to-be-tested register in the target storage space comprises the following steps: acquiring a target identifier of the to-be-tested register and determining a storage location of target standard data matched with the target identifier in the target storage space; acquiring the standard field data in the target standard data based on the storage location comprises the following steps: acquiring sub-data in the target standard data based on the storage location and storing the sub-data into a first data structure according to a position state of the sub-data to obtain the standard field data; acquiring the sub-data in the target standard data based on the storage location and storing the sub-data into a first data structure according to a position state of the sub-data to obtain the standard field data comprises the following steps: traversing target storage data at the storage location in the target storage space; if the traversed target storage data does not belong to preset invalid character data, storing the target storage data into a second temporary array to obtain different sub-data in the target standard data; determining a data attribute of the sub-data according to a position state of the traversal and storing the sub-data into the first data structure in sequence after conversion processing according to the data attribute to obtain the standard field data.
2. The method for testing registers according to claim 1, characterized in that, determining the storage location of the target standard data matched with the target identifier in the target storage space comprises the following steps: traversing storage data at each offset address in the target storage space; if the traversed storage data does not belong to preset invalid character data, storing the storage data into a first temporary array to obtain valid character data; comparing the valid character data with the target identifier; if the comparison is consistent, storing an offset address of the valid character data into a preset standard address array to obtain the storage location of the target standard data; if the comparison is inconsistent, clearing the valid character data in the first temporary array and continuing to traverse storage data at a next offset address in the target storage space.
3. The method for testing registers according to claim 1, wherein, The data attribute comprises offset data, length data, name character and value data. The standard field data is obtained by sequentially storing the sub-data after converting the sub-data according to the data attribute, respectively, into a first data structure. The sub-data with the data attribute of offset data is converted into a first binary through a string conversion function and stored into a first variable. The sub-data with the data attribute of length data is converted into a second binary through the string conversion function and stored into a second variable. The sub-data with the data attribute of name character is copied into a third variable through a copy function. The sub-data with the data attribute of numerical data is converted into the first binary through the string conversion function and stored into a fourth variable. The first data structure is constructed according to the first variable, the second variable, the third variable and the fourth variable to obtain the standard field data.
4. The method for testing registers according to claim 3, characterized in that, The measured initial value corresponding to the standard field data is read from the measured register according to the type of the measured register, including: According to the type of the measured register, a corresponding read instruction is called to read the measured field data of the measured register and store it into a target buffer space. The measured initial value in the measured field data is read from the target buffer space according to the first variable and the second variable.
5. The method for testing registers according to claim 4, characterized in that, The measured initial value in the measured field data is read from the target buffer space according to the first variable and the second variable, including: The measured field data with a size of the second variable is read from the target buffer space with the first variable as a starting address to obtain the measured initial value.
6. The method for testing registers according to claim 4, wherein, The measured initial value is checked according to the standard field data to obtain a check result, including: The fourth variable is compared with the measured initial value to determine whether they are consistent; If they are consistent, it is determined that the measured initial value corresponding to the standard field data passes the check; If they are not consistent, it is determined that the measured initial value corresponding to the standard field data fails the check; The test result of the measured register is generated according to the check result, including: The test result of the measured register is generated according to the check result of all the standard field data in the target standard data.
7. The method for testing registers according to claim 1, wherein, Before loading the standard data of all the registers in the preset file into the target storage space, it further includes: The preset file is stored into a non-volatile storage address of a storage device through a serial port loading function.
8. A storage device, comprising: The storage chip stores a computer program, and the computer program is executed by the control chip to realize each step in the method for testing the register according to any one of claims 1-7.
Citation Information
Patent Citations
Register checking method and device and storage medium
CN115729752A