Ufs test case monitoring method and device, equipment and storage medium

Abstract

The invention provides a ufs test case monitoring method and device, equipment and a storage medium, applied to a ufs verification platform, the ufs verification platform is in communication connection with to-be-tested equipment provided with ufs, and the method comprises the steps that the ufs verification platform generates at least one target instruction based on a ufs test case, and sends all the target instructions to the to-be-tested equipment in sequence, the to-be-tested device executes a target test based on the target instruction; the ufs verification platform writes all the target instructions and related information thereof into a record file, and the related information comprises logic unit numbers, logic block addresses and the number of blocks of the target instructions; and the ufs verification platform generates an end signal and sends the end signal to the to-be-tested device and the record file, the to-be-tested device terminates the target test, the ufs test case terminates, and the record file terminates writing. According to the technical scheme of the embodiment of the invention, all the target instructions and related information thereof can be recorded, so that the troubleshooting speed and efficiency of the ufs test result are improved.

Description

Technical Field

[0001] This invention relates to the field of UFS test case monitoring technology, and in particular to a UFS test case monitoring method, apparatus, device, and storage medium. Background Technology

[0002] Before Universal Flash Storage (ufs) ships from the factory, it needs to be tested. Currently, the ufs verification platform connects to multiple devices under test (DUTs), each with ufs installed. The ufs verification platform uses ufs test cases to perform read, erase, and write tests on the DUTs, thereby determining the ufs test results.

[0003] During read / write tests, when UFS test results show errors, troubleshooting is required. Currently, UFS troubleshooting can be performed using a UFS protocol analyzer, or by analyzing the logical address and block address count of the erroneous UFS output by a UFS verification platform. While a UFS protocol analyzer can capture the entire UFS protocol process and perform fault analysis, its high cost makes it difficult to widely apply to troubleshooting batches of UFS. Therefore, currently, troubleshooting is more often done manually, item by item, based on the logical address and block address count of the erroneous UFS output by the UFS verification platform. However, this method is inefficient, fails to reveal the specific operations performed when the UFS malfunctions, and is not conducive to locating and troubleshooting the problem. Summary of the Invention

[0004] This invention aims to at least solve one of the technical problems existing in the prior art. To this end, this invention proposes a method, apparatus, device, and storage medium for monitoring UFS test cases, capable of recording all target instructions and their related information, thereby improving the speed and efficiency of troubleshooting UFS test results.

[0005] In a first aspect, embodiments of the present invention provide a method for monitoring UFS test cases, applied to a UFS verification platform, wherein the UFS verification platform is communicatively connected to a device under test, and the device under test has UFS installed; the method includes: The UFS verification platform generates at least one target instruction based on UFS test cases, and sends all the target instructions to the device under test in sequence. The device under test executes target tests based on the target instructions. The target instructions include target read instructions, target write instructions, or target erase instructions. The UFS verification platform writes all the target instructions and all the related information of the target instructions to a log file, wherein the related information includes the logical unit number, logical block address and number of blocks of the target instructions; The UFS verification platform generates an end signal and sends the end signal to the device under test and the log file respectively. The device under test terminates the target test, the UFS test case terminates, and the writing to the log file stops.

[0006] According to some embodiments of the present invention, the UFS verification platform includes a use case layer, an interface layer, and a driver layer. The use case layer includes the UFS test cases. The interface layer is communicatively connected to the use case layer and the driver layer, respectively. The driver layer is communicatively connected to the device under test. The UFS verification platform generates at least one target instruction based on UFS test cases, and sequentially sends all the target instructions to the device under test, including: The test case layer generates at least one operation instruction based on the ufs test case, and the test case layer sends all the operation instructions to the interface layer in sequence. The operation instructions include write instructions, read instructions, or erase instructions. Based on any of the operation instructions, the interface layer performs format conversion on the operation instructions to obtain the target instruction, the interface layer sends the target instruction to the driver layer, and the driver layer sends the target instruction to the device under test.

[0007] According to some embodiments of the present invention, the UFS verification platform includes a main thread and a sub-thread; The UFS verification platform writes all the target instructions and related information of all the target instructions to a log file, including: The main thread calls the interface layer through the use case layer to add the relevant information to the global queue, wherein both the main thread and the child thread can access the global queue; The sub-thread retrieves the relevant information from the global queue and writes it to the record file.

[0008] According to some embodiments of the present invention, the sub-thread retrieves the relevant information from the global queue and writes the relevant information to the record file, including: When the device under test executes the UFS test case, the sub-thread is started, and the sub-thread queries whether the global queue is empty. When the global queue is found to be non-empty, the sub-thread retrieves the relevant information from the global queue and writes the relevant information into the record file.

[0009] According to some embodiments of the present invention, after writing the relevant information into the record file, the method further includes: The sub-thread determines whether it has received the termination signal. If the termination signal is received, the sub-thread terminates. If the termination signal is not received, the child thread checks the global queue again to see if it is empty.

[0010] According to some embodiments of the present invention, the UFS verification platform generates an end signal and sends the end signal to the device under test and the log file respectively. The device under test terminates the target test, the UFS test case terminates, and the writing to the log file terminates, including: The use case layer generates the end signal and calls the interface layer to send the end signal to the driver layer; The driver layer sends the end signal to the device under test, the device under test terminates the target test, and the UFS test case ends; The interface layer sends the end signal to the global queue. After the sub-thread writes all the relevant information to the log file, the log file receives the end signal, stops writing, and is stored on the UFS protocol platform.

[0011] According to some embodiments of the present invention, the interface layer includes a write interface, a read interface, and an erase interface; The main thread calls the interface layer through the use case layer to add the relevant information to the global queue, including: When the target instruction is a target write instruction, the use case layer calls the write interface to add the relevant information of the target instruction and the write operation to the global queue; When the target instruction is a target read instruction, the use case layer calls the read interface to add the relevant information of the target instruction and the read operation to the global queue; When the target instruction is a target erase instruction, the use case layer calls the erase interface to add the relevant information of the target instruction and the erase operation to the global queue.

[0012] Secondly, embodiments of the present invention provide a monitoring device for UFS test cases, including at least one control processor and a memory for communicatively connecting to the at least one control processor; the memory stores instructions executable by the at least one control processor, which are executed by the at least one control processor to enable the at least one control processor to perform the monitoring method for UFS test cases as described in the first aspect above.

[0013] Thirdly, embodiments of the present invention provide an electronic device including a monitoring device for UFS test cases as described in the second aspect above.

[0014] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer-executable instructions for executing the monitoring method for UFS test cases as described in the first aspect above.

[0015] The monitoring method for UFS test cases according to embodiments of the present invention has at least the following beneficial effects: the method is applied to a UFS verification platform, the UFS verification platform is communicatively connected to a device under test (DUT), and the DUT is equipped with UFS. The method includes: the UFS verification platform generating at least one target instruction based on UFS test cases, sequentially sending all the target instructions to the DUT, and the DUT executing a target test based on the target instructions, wherein the target instructions include a target read instruction, a target write instruction, or a target erase instruction; the UFS verification platform writing all the target instructions and related information of all the target instructions to a log file, wherein the related information includes the logical unit number, logical block address, and number of blocks of the target instructions; the UFS verification platform generating an end signal, sending the end signal to the DUT and the log file respectively, the DUT terminating the target test, the UFS test case terminating, and the log file ceasing writing. According to the technical solution of the present invention, the target instructions generated by the UFS protocol platform and related information of the target instructions are recorded in a log file, the log file including the specific operation corresponding to the target instruction, the logical unit number, the logical block address, and the number of blocks. When a UFS test case reports an error, the corresponding target instruction can be determined based on the UFS logical address, block address number, correct data, and erroneous data output by the faulty device under test. This allows for the identification of the corresponding operation, facilitating the location of specific problems and rapid troubleshooting. Attached Figure Description

[0016] Figure 1 This is a flowchart of a monitoring method for UFS test cases provided in one embodiment of the present invention; Figure 2 This is a structural diagram of the UFS verification platform provided in another embodiment of the present invention; Figure 3 This is a flowchart of the main thread provided in another embodiment of the present invention; Figure 4 This is a flowchart of a sub-thread provided in another embodiment of the present invention; Figure 5 This is a structural diagram of a monitoring device for ufs test cases provided in another embodiment of the present invention. Detailed Implementation

[0017] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0018] In the description of this invention, it should be understood that the orientation descriptions, such as up, down, front, back, left, right, etc., are based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.

[0019] In the description of this invention, "several" means one or more, "more than" means two or more, "greater than," "less than," and "exceeding" are understood to exclude the stated number, while "above," "below," and "within" are understood to include the stated number. The use of "first" and "second" in the description is merely for distinguishing technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the order of the indicated technical features.

[0020] In the description of this invention, unless otherwise explicitly defined, terms such as "set up," "install," and "connect" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this invention in conjunction with the specific content of the technical solution.

[0021] The monitoring method for UFS test cases according to embodiments of the present invention has at least the following beneficial effects: the method is applied to a UFS verification platform, the UFS verification platform is communicatively connected to a device under test (DUT), and the DUT is equipped with UFS. The method includes: the UFS verification platform generating at least one target instruction based on UFS test cases, sequentially sending all the target instructions to the DUT, and the DUT executing a target test based on the target instructions, wherein the target instructions include a target read instruction, a target write instruction, or a target erase instruction; the UFS verification platform writing all the target instructions and related information of all the target instructions to a log file, wherein the related information includes the logical unit number, logical block address, and number of blocks of the target instructions; the UFS verification platform generating an end signal, sending the end signal to the DUT and the log file respectively, the DUT terminating the target test, the UFS test case terminating, and the log file ceasing writing. According to the technical solution of the present invention, the target instructions generated by the UFS protocol platform and related information of the target instructions are recorded in a log file, the log file including the specific operation corresponding to the target instruction, the logical unit number, the logical block address, and the number of blocks. When a UFS test case reports an error, the corresponding target instruction can be determined based on the UFS logical address, block address number, correct data, and erroneous data output by the faulty device under test. This allows for the identification of the corresponding operation, facilitating the location of specific problems and rapid troubleshooting.

[0022] The technical solutions of the embodiments of the present invention will be further illustrated in the following figures.

[0023] Reference Figure 1 , Figure 1 The flowchart illustrates a UFS test case monitoring method provided in this embodiment of the invention. This method is applied to a UFS verification platform, which is communicatively connected to the device under test (DUT). The DUT has UFS installed. The UFS test case monitoring method includes, but is not limited to, the following steps: S10, the UFS verification platform generates at least one target instruction based on the UFS test cases, and sends all the target instructions to the device under test in sequence. The device under test executes the target test based on the target instructions. The target instructions include target read instructions, target write instructions or target erase instructions. S20, the UFS verification platform writes all target instructions and related information of all target instructions to a log file. The related information includes the logical unit number, logical block address and number of blocks of the target instruction. S30, the UFS verification platform generates an end signal and sends the end signal to the device under test and the log file respectively. The device under test terminates the target test, the UFS test case terminates, and the log file stops writing.

[0024] It should be noted that the UFS verification platform is the host side, and the device under test is the device side. The UFS verification platform is located on the embedded multimedia card (eMMc) and is implemented in the Linux system.

[0025] It should be noted that UFS test cases are programs developed in Python or C language, used to test the device under test with UFS installed. Each UFS test case includes at least one test operation and generates at least one target instruction based on the UFS test case. The target instruction corresponds to the test operation, which includes read operation, write operation and erase operation.

[0026] It should be noted that the UFS test cases are used to test the device under test with UFS installed. The UFS test cases include the UFS verification platform, which consists of the application layer, the kernel layer, and the device under test. The kernel layer communicates with both the application layer and the device under test. It should be noted that the device under test (DUT) is equipped with UFS, meaning the DUT is a UFS device. Relevant information includes the logical unit number (LUN), logical block address (LBA), and number of blocks (CNT) of the target instruction. LUN is the logical unit number of the UFS, i.e., the logical partition of the UFS, typically between 0 and 7; LBA is the logical address of the UFS or eMMC, i.e., the starting logical address of the target instruction; and CNT is the number of blocks in the target instruction.

[0027] It should be noted that all target instructions based on a UFS test case are recorded in the same log file. Each log file is associated with only one UFS test case, which makes it easy for operators to query the corresponding UFS test case and select the log file associated with it, and then locate the problem and troubleshoot based on the log file.

[0028] It should be noted that in the existing technology, when testing the device under test using UFS test cases, and then reading erroneous data from the UFS of the device under test after the test, the tester needs to troubleshoot the device under test. However, since the specific target instructions and corresponding operations performed by the UFS test cases on the device under test are unknown, it is impossible to know the specific operations when the UFS malfunctions, making it difficult to locate the problem and troubleshoot. Alternatively, each piece of data written to the same address of the device under test (DUT) may be different. However, during the UFS test case process, the UFS test case might write data to the same address of the DUT twice. The second write should overwrite the first write, but the data read back from the DUT is the first write. In this case, the UFS test case considers the data to have been written twice, but the DUT considers the UFS test case to have only written the data once. Based on this situation, due to the lack of tools to detect read, write, and erase operations, it is difficult to locate the problem and troubleshoot. Or, before the UFS test case is put into use, it needs to be designed. For example, the UFS test case is designed to perform random read and write operations within the address range of 0-1000. However, since the UFS test case does not report errors, the logical address and block address number cannot be obtained, and it is impossible to verify whether the UFS test case can run as designed. Currently, there is a lack of monitoring methods for verifying whether the read, write, and erase operations of the UFS test case meet expectations. To address the aforementioned issues, a UFS logic analyzer can be used to capture the entire UFS protocol process of UFS test cases and analyze it to troubleshoot. However, due to the high cost of UFS logic analyzers, it is not suitable for analyzing devices under test that require batch testing. Furthermore, based on the UFS logical address, block address count, correct data, and erroneous data output by the faulty device under test, it is difficult to pinpoint the specific problem. Moreover, regarding verification issues in the UFS test case design process, when UFS test cases do not report errors, it is unclear whether the UFS test case design is correct or contains errors due to design flaws, making it impossible to determine the outcome.

[0029] It should be noted that the monitoring method for UFS test cases in this application records the target instructions generated by the UFS protocol platform and related information of the target instructions in a log file. The log file includes the specific operation corresponding to the target instruction, the logical unit number, the logical block address, and the number of blocks. When a UFS test case reports an error, the corresponding target instruction can be determined based on the UFS logical address, the number of block addresses, the correct data, and the erroneous data output by the device under test, thereby determining the corresponding operation. This facilitates the localization of specific problems and the rapid completion of troubleshooting.

[0030] Additionally, in one embodiment, reference is made to Figure 2 , Figure 2This is a structural diagram of a UFS verification platform provided in another embodiment of the present invention. The UFS verification platform includes a use case layer, an interface layer, and a driver layer. The use case layer includes UFS test cases. The interface layer is communicatively connected to both the use case layer and the driver layer. The driver layer is communicatively connected to the device under test. Figure 1 In step S10, the UFS verification platform generates at least one target instruction based on the UFS test cases and sends all target instructions to the device under test sequentially, including but not limited to the following steps: S11, the test case layer generates at least one operation instruction based on the ufs test case, and the test case layer sends all operation instructions to the interface layer in sequence. The operation instructions include write instructions, read instructions or erase instructions. S12, based on any operation command, the interface layer converts the operation command into a target command, the interface layer sends the target command to the driver layer, and the driver layer sends the target command to the device under test.

[0031] It should be noted that the UFS verification platform includes an application layer, a kernel layer, and the device under test. The application layer includes a use case layer and an interface layer, and the kernel layer includes a driver layer.

[0032] It should be noted that the test case layer uses the C language to design and develop various UFS test cases, and can generate write, read, or erase commands based on the UFS test cases. The test case layer can call the interface layer to send operation commands to the driver layer.

[0033] It should be noted that the interface layer provides read, write, and erase interfaces for the use case layer. The interface layer can convert operation commands into target commands with a consistent format. For example, in this application, the UFS protocol platform is the host side, and the device under test is the device side. To achieve communication between the host and device, the standard interface protocol of Small Computer System Interface (SCSI) is used for communication transmission between them. When the UFS protocol platform generates operation commands, the interface layer performs format conversion based on the operation commands to obtain the target commands, which are SCSI commands. For example, the read interface is `int ufs_read10(u8 lun, u32 lba, u32 blk_cnt, u8* buf)`, the write interface is `int ufs_write10(u8 lun, u32 lba, u32 blk_cnt, u8* buf)`, and the erase interface is `int ufs_unmap(u8 lun, u16 param_list_length, u8 *buf)`.

[0034] It should be noted that the driver layer communicates with both the interface layer and the device under test (DUT). The driver layer is used to obtain target instructions and send them to the DUT. It is a UFS driver used to send the target instructions generated by the interface layer to the DUT.

[0035] Additionally, in one embodiment, reference is made to Figure 3 and Figure 4 , Figure 3 This is a flowchart of the main thread provided in another embodiment of the present invention. Figure 4 This is a flowchart of a sub-thread provided in another embodiment of the present invention. The UFS verification platform includes a main thread and sub-threads. Figure 1 Step S20 shown includes, but is not limited to, the following steps: S21, the main thread adds relevant information to the global queue by calling the interface layer through the use case layer. Both the main thread and the child thread can access the global queue. S22, the child thread retrieves the relevant information from the global queue and writes it to the log file.

[0036] It should be noted that when recording information related to the target instruction, each item needs to be written to a log file. When both the target instruction and its recording are handled by a single thread, the relevant information must be written to the log file before executing the target instruction. While this allows for recording of the target instruction, facilitating troubleshooting when UFS test cases report errors, it increases the testing time for the device under test and reduces testing efficiency. To address this issue, the execution and recording of the target instruction are handled by a main thread and a child thread, respectively. A global queue accessible to both the main and child threads is added to facilitate variable exchange between them.

[0037] It should be noted that in the main thread, the test case layer generates operation instructions and sends them to the interface layer. The interface layer performs format conversion based on the operation instructions to obtain the target instructions. The test case layer calls the read interface, write interface, or erase interface of the interface layer and sends the target instructions to the device under test through the driver layer. The device under test executes the target instructions and generates test results based on the execution results.

[0038] It should be noted that in the child thread, the relevant information in the global queue is retrieved one by one based on the first-in-first-out (FIFO) algorithm and recorded in the log file. The child thread continuously checks whether the global queue is empty. When the global queue is not empty, that is, when there is data in the global queue, the relevant information is retrieved from the tail of the global queue and written to the log file.

[0039] It should be noted that when the test case layer calls the read, write, or erase interface of the interface layer, the interface layer adds relevant information such as the logical unit number, logical block address, and number of blocks of the target read, write, or erase operation to the head of the global queue. The child thread retrieves the relevant information one by one from the tail of the global queue and writes the retrieved information one by one to the log file. When the UFS test case finishes execution, the test case layer generates and sends a termination signal to the child thread, which then terminates and exits upon receiving the termination signal.

[0040] It should be noted that by setting up a global queue, the driver layer can simultaneously acquire target instructions and send them to the device under test, and add relevant information to the global queue and retrieve relevant information from the global queue to write to a log file. In other words, through this embodiment, while ensuring the testing speed and performance of UFS test cases on the device under test, it is also possible to monitor UFS test cases and record the logical unit number, logical block address, and number of blocks of all target instructions, so as to facilitate subsequent problem location and troubleshooting, without affecting the original UFS test performance.

[0041] It should be noted that since the time required to write relevant information to the log file is longer than the time required to write relevant information to the global queue, which is similar to a cache and can store relevant information for multiple target instructions, the writing speed of the sub-thread does not affect the execution of the UFS test cases.

[0042] Additionally, in one embodiment, in Figure 1 Step S22 shown also includes, but is not limited to, the following steps: S221, When the device under test executes the UFS test case, a sub-thread is started, and the sub-thread checks whether the global queue is empty; S222, when the global queue is found to be non-empty, the child thread retrieves the relevant information from the global queue and writes the relevant information to the log file.

[0043] It should be noted that after the child thread starts, it continuously checks whether the global queue is empty. When the global queue is not empty, the child thread retrieves the relevant information from the global queue and writes the relevant information to the log file. The relevant information is written to the log file in the same format. For example, the log format is W / R:lun-lba-cnt, where W / R represents a write operation or a read operation. After the colon, the logical unit number, starting logical address, and number of blocks of the read operation or write operation are recorded in sequence. W:0-48746360-8 indicates that the logical unit number of the write operation is 0, the starting logical address is 48746360, and the number of blocks is 8.

[0044] Additionally, in one embodiment, in Figure 1In step S222 shown, after writing the relevant information to the record file, the following steps are included, but are not limited to: S2221, the child thread checks whether it has received an end signal. If it receives an end signal, the child thread terminates. S2222, when no end signal is received, the child thread checks the global queue again to see if it is empty.

[0045] It should be noted that the child thread continuously checks whether the global queue is empty to ensure that the child thread can retrieve the relevant information as soon as possible and record it to the log file, thereby recording all relevant information of the target instruction.

[0046] It should be noted that by terminating the child thread with the termination signal, a log file is made to record all the target instructions of only one UFS test case. This avoids the situation where the target instructions of multiple UFS test cases are mixed in one file, making it difficult for testers to locate problems and troubleshoot based on the log file.

[0047] Additionally, in one embodiment, in Figure 1 Step S30 shown includes, but is not limited to, the following steps: S31, the use case layer generates an end signal, and the calling interface layer sends the end signal to the driver layer; S32, the driver layer sends an end signal to the device under test, the device under test terminates the target test, and the ufs test case ends; S33, the interface layer sends the end signal to the global queue. After the child thread writes all relevant information to the log file, the log file receives the end signal, stops writing to the log file, and saves the log file on the UFS protocol platform.

[0048] It should be noted that when all operation instructions are generated based on the UFS test case, the test case layer generates an end signal and sends it to the device under test (DUT) through the interface layer. This causes the DUT to terminate the target test after completing all target instructions, thus ending the UFS test case. The end signal is also sent to the DUT and the global queue through the interface layer. After the child thread writes all relevant information to the log file, it retrieves the end signal from the global queue, stops writing to the log file, and saves the log file to the UFS protocol platform. This facilitates subsequent troubleshooting and problem identification by operators based on the log file, and ensures that one UFS test case corresponds to only one log file.

[0049] In another embodiment, the interface layer includes a write interface, a read interface, and an erase interface. Figure 1 Step S21 shown also includes, but is not limited to, the following steps: S223, when the target instruction is a target write instruction, the use case layer calls the write interface to add the relevant information of the target instruction and the write operation to the global queue; S224, when the target instruction is a target read instruction, the use case layer calls the read interface to add the relevant information of the target instruction and the read operation to the global queue; S225, when the target instruction is a target erase instruction, the use case layer calls the erase interface to add the relevant information of the target instruction and the erase operation to the global queue.

[0050] It should be noted that after the interface layer obtains the target instruction by converting the format based on the operation instruction, it determines the specific operation of the target instruction. When the target instruction is a target write instruction, the test case layer calls the write interface of the interface layer to send the target write instruction to the device under test and adds the write operation and related information to the global queue. When the target instruction is a target read instruction, the test case layer calls the read interface of the interface layer to send the target read instruction to the device under test and adds the read operation and related information to the global queue. When the target instruction is a target erase instruction, the test case layer calls the erase interface of the interface layer to send the target erase instruction to the device under test and adds the erase operation and related information to the global queue.

[0051] To facilitate understanding of the technical solution of this application, the following embodiments are provided: S401, the UFS verification platform starts up and selects a UFS test case. S402, in the main thread, at least one operation instruction is generated based on the UFS test case; based on any operation instruction, the interface layer obtains the operation instruction and converts it into a target instruction; when the test case layer calls the interface layer to send the target instruction to the driver layer, the interface layer writes the target instruction and related information of the target instruction to the head of the global queue; S403, in the sub-thread, continuously check whether the head of the global queue is empty. When the interface layer sends the target instruction and its related information to the head of the global queue, and the global queue is not empty, the sub-thread retrieves the target instruction and its related information from the tail of the global queue and writes the target instruction and its related information to the log file one by one. S404 In the main thread, after the driver layer obtains the target instruction, it sends the target instruction to the device under test, and the device under test executes the test corresponding to the target instruction based on the target instruction; S405, in the main thread, after the UFS test case generates all the operation instructions, the UFS test case located in the test case layer generates an end signal. The interface layer obtains the end signal and performs format conversion on the end signal to obtain the target end signal. When the test case layer calls the interface layer to send the target end signal to the driver layer, the interface layer sends the target end signal to the head of the global queue. S406, in the main thread, when the driver layer obtains the target end signal, it sends the target end signal to the device under test, the device under test terminates the target test, and the UFS test case terminates. S407, in the child thread, after the child thread writes all relevant information of the global queue to the log file, the target end signal is located at the tail of the global queue. When the child thread writes the target end signal to the log file, the log file ends and is saved in the UFS verification platform.

[0052] Through the complete technical solution of this invention, using a main thread, sub-threads, and a global queue, the main thread writes the target instruction and its related information into the global queue. Then, the main thread sends the target instruction to the device under test (DUT) through the driver layer, enabling the DUT to execute the target test. This eliminates the need to wait for the target instruction and its related information to be written to a log file before sending the target instruction to the DUT. As a result, while maintaining the original test speed and performance of UFS test cases, the target instruction and all its related information generated based on the UFS test cases are recorded to a log file, which improves the speed and efficiency of troubleshooting UFS test results.

[0053] like Figure 5 As shown, Figure 5 This is a structural diagram of a UFS test case monitoring device provided in one embodiment of the present invention. The present invention also provides a UFS test case monitoring device, comprising: The processor 501 can be implemented using a general-purpose central processing unit (CPU), microprocessor, application specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 502 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 502 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 502 and is called by the processor 501 to execute the monitoring method of the UFS test cases in the embodiments of this application. The input / output interface 503 is used to implement information input and output; The communication interface 504 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 505 transmits information between various components of the device (e.g., processor 501, memory 502, input / output interface 503, and communication interface 504); The processor 501, memory 502, input / output interface 503, and communication interface 504 are connected to each other within the device via bus 505.

[0054] This application also provides an electronic device, including a monitoring device for the ufs test cases as described above.

[0055] This application embodiment also provides a storage medium, which is a computer-readable storage medium, storing a computer program that, when executed by a processor, implements the monitoring method for the above-described UFS test cases.

[0056] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof. The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate, and may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0057] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically include computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0058] The above provides a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.

Claims

1. A method for monitoring UFS test cases, characterized in that, Applied to a UFS verification platform, wherein the UFS verification platform is communicatively connected to the device under test (DUT), and the DUT has UFS installed, the method includes: The UFS verification platform generates at least one target instruction based on UFS test cases, and sends all the target instructions to the device under test in sequence. The device under test executes target tests based on the target instructions, wherein the target instructions include target read instructions, target write instructions, or target erase instructions. The UFS verification platform writes all the target instructions and all the related information of the target instructions to a log file, wherein the related information includes the logical unit number, logical block address and number of blocks of the target instructions; The UFS verification platform generates an end signal and sends the end signal to the device under test and the log file respectively. The device under test terminates the target test, the UFS test case terminates, and the writing to the log file stops.

2. The monitoring method for UFS test cases according to claim 1, characterized in that, The UFS verification platform includes a use case layer, an interface layer, and a driver layer. The use case layer includes the UFS test cases. The interface layer is communicatively connected to the use case layer and the driver layer. The driver layer is communicatively connected to the device under test. The UFS verification platform generates at least one target instruction based on UFS test cases, and sequentially sends all the target instructions to the device under test, including: The test case layer generates at least one operation instruction based on the ufs test case, and the test case layer sends all the operation instructions to the interface layer in sequence. The operation instructions include write instructions, read instructions, or erase instructions. Based on any of the operation instructions, the interface layer performs format conversion on the operation instructions to obtain the target instruction, the interface layer sends the target instruction to the driver layer, and the driver layer sends the target instruction to the device under test.

3. The monitoring method for UFS test cases according to claim 2, characterized in that, The UFS verification platform includes a main thread and sub-threads; The UFS verification platform writes all the target instructions and related information of all the target instructions to a log file, including: The main thread calls the interface layer through the use case layer to add the relevant information to the global queue, wherein both the main thread and the child thread can access the global queue; The sub-thread retrieves the relevant information from the global queue and writes it to the record file.

4. The monitoring method for UFS test cases according to claim 3, characterized in that, The sub-thread retrieves the relevant information from the global queue and writes it to the record file, including: When the device under test executes the UFS test case, the sub-thread is started, and the sub-thread queries whether the global queue is empty. When the global queue is found to be non-empty, the sub-thread retrieves the relevant information from the global queue and writes the relevant information into the record file.

5. The monitoring method for UFS test cases according to claim 4, characterized in that, After writing the relevant information into the record file, the process also includes: The sub-thread determines whether it has received the termination signal. If the termination signal is received, the sub-thread terminates. If the termination signal is not received, the child thread checks the global queue again to see if it is empty.

6. The monitoring method for UFS test cases according to claim 2, characterized in that, The UFS verification platform generates an end signal and sends the end signal to the device under test and the log file respectively. The device under test terminates the target test, the UFS test case terminates, and the writing to the log file terminates, including: The use case layer generates the end signal and calls the interface layer to send the end signal to the driver layer; The driver layer sends the end signal to the device under test, the device under test terminates the target test, and the UFS test case ends; The interface layer sends the end signal to the global queue. After the sub-thread writes all the relevant information to the log file, the log file receives the end signal, stops writing, and is stored on the UFS protocol platform.

7. The monitoring method for UFS test cases according to claim 3, characterized in that, The interface layer includes a write interface, a read interface, and an erase interface; The main thread calls the interface layer through the use case layer to add the relevant information to the global queue, including: When the target instruction is a target write instruction, the use case layer calls the write interface to add the relevant information of the target instruction and the write operation to the global queue; When the target instruction is a target read instruction, the use case layer calls the read interface to add the relevant information of the target instruction and the read operation to the global queue; When the target instruction is a target erase instruction, the use case layer calls the erase interface to add the relevant information of the target instruction and the erase operation to the global queue.

8. A monitoring device for UFS test cases, characterized in that, It includes at least one control processor and a memory for communicatively connecting to the at least one control processor; the memory stores instructions executable by the at least one control processor to enable the at least one control processor to perform the monitoring method for the ufs test cases as described in any one of claims 1 to 7.

9. An electronic device, characterized in that, The monitoring device includes the ufs test case as described in claim 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing a computer to perform the monitoring method for the ufs test cases as described in any one of claims 1 to 7.

Images