Bus equipment testing method, device and system

The bus device testing system addresses the limitation of restricted host computers by using a protocol-convertible test end for efficient and universal testing of I3C devices, enhancing test efficiency and convenience.

CN119149463APending Publication Date: 2024-12-17SHANDONG YUNHAI GUOCHUANG CLOUD COMPUTING EQUIP IND INNOVATION CENT CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411161647.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-08-22
Publication Date
2024-12-17

AI Technical Summary

Technical Problem

Existing bus device testing methods require a host computer that supports the I3C protocol, limiting test efficiency and convenience due to restricted device compatibility.

Method used

A bus device testing system with a test end configured with both a first and second protocol interface, enabling data conversion between a host computer and a device under test, allowing for universal and efficient testing by parsing and determining target data types using custom command codes.

Benefits of technology

Facilitates efficient and universal bus device testing by enabling communication between general host computers and I3C devices, simplifying the test process and improving efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119149463A_ABST
    Figure CN119149463A_ABST
Patent Text Reader

Abstract

The invention provides a bus equipment testing method, device and system, and the method comprises the steps: responding to downlink data sent by an upper computer end and received by a first protocol interface, carrying out the analysis of the downlink data through a testing end, determining first target data to be transmitted, transmitting the first target data to a to-be-tested equipment end through a second protocol interface, and transmitting the first target data to the to-be-tested equipment end, and receiving uplink data sent by the to-be-tested device end in response to the second protocol interface, analyzing the uplink data through the test end, determining to-be-transmitted second target data, transmitting the second target data to the upper computer end through the first protocol interface, and determining an uplink data test result. The upper computer is directly connected with the test end through the first protocol interface, the test end is mounted on the I3C bus through the second protocol interface, the upper computer is used for sending and receiving data to the to-be-tested bus equipment on the bus through the test end so as to test and verify the bus equipment, and the test is efficiently completed.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a bus device testing method, device and system. Background Art

[0002] With the development of large-scale integrated circuits, in pursuit of ease of use, the central processing unit and other external devices were gradually integrated on a single chip, called a single-chip microcomputer. Therefore, how to achieve interconnection between chips and peripherals within the limited area of ​​the circuit board and minimize the number of lines while ensuring secure data transmission became a problem at the time.

[0003] The MIPI (Mobile Industry Processor Interface) Alliance developed the I3C (Improved Inter-Integrated Circuit) protocol based on the I2C protocol in order to unify the sensor communication protocol. The I3C protocol uses two strict wires for transmission, and the interrupt is integrated in the IBI (in-band interrupt) for transmission. In the I3C protocol, the SCL line uses push-pull output, and the SDA line is push-pull and open-drain optional. The power consumption is significantly lower than the I2C protocol with both wires open-drain output, which improves the bus transmission rate. In addition, the I3C protocol supports hot plugging, and has many other powerful functions such as CCC (Common Command Codes), etc., and is forward compatible with the I2C protocol, so the I3C protocol is gradually being put into use.

[0004] However, since the I3C protocol is mainly used for communication between board-level peripherals and MCUs, commonly used personal computers cannot be directly connected to the I3C bus for testing. This requires that when performing communication tests on a certain I3C device alone, a device that supports the I3C protocol and can perform input and output must be used as the host computer. In this way, the host computer selected to test the I3C device is subject to strong restrictions, resulting in inconvenience in testing, which in turn affects the test efficiency of the I3C device. Summary of the invention

[0005] In view of this, the present invention aims to propose a bus device testing method, device and system to solve the problem that the current bus device testing must use a device that supports the I3C protocol and can perform input and output as a host computer, which is inconvenient to test and affects the test efficiency of the I3C device, and realize universal and efficient bus device testing.

[0006] According to a first aspect of the present invention, a bus device testing method is provided, which is applied to a bus device testing system, wherein the system comprises a host computer end, a test end and a device under test end, wherein the test end is configured with a first protocol interface and a second protocol interface, wherein the test end is connected to the host computer end via the first protocol interface, and is connected to the device under test end via the second protocol interface, wherein the method comprises:

[0007] In response to the first protocol interface receiving the downlink data sent by the host computer end, the test end parses the downlink data to determine the first target data to be transmitted;

[0008] Transmitting the first target data to the device under test through the second protocol interface, and determining a downlink data test result;

[0009] In response to the second protocol interface receiving the uplink data sent by the device under test, the test end parses the uplink data to determine the second target data to be transmitted;

[0010] The second target data is transmitted to the host computer through the first protocol interface, and an uplink data test result is determined.

[0011] Optionally, in response to the first protocol interface receiving the downlink data sent by the host computer end, parsing the downlink data by the test end to determine the first target data to be transmitted includes:

[0012] Generate downlink data in advance through the host computer; wherein the downlink data includes a custom command code and first test data;

[0013] In response to the first protocol interface receiving the downlink data sent by the host computer, storing the downlink data in the test terminal;

[0014] Parsing the downlink data through the test end to obtain a custom command code and first test data in the downlink data;

[0015] The custom command code is used to determine the data type corresponding to the downlink data; wherein the data type includes a command type and a configuration type;

[0016] If the data type corresponding to the downlink data is a command type, the first test data is determined as the first target data to be transmitted to the device under test.

[0017] Optionally, if the data type corresponding to the downlink data is a command type, determining the first test data as first target data to be transmitted to the device under test includes:

[0018] The test end compares the custom command code with the general command code of the device under test to determine the target command corresponding to the custom command code;

[0019] The target command and the first test data are determined as first target data to be transmitted to the device under test, and the first target data is stored in a preset downlink buffer area.

[0020] Optionally, the use of the custom command code to determine the data type corresponding to the downlink data; wherein the data type includes, after the command type and the configuration type, further includes:

[0021] If the data type corresponding to the downlink data is a configuration type, modifying the configuration of the test end according to the first test data;

[0022] If the data type corresponding to the downlink data does not satisfy the command type and the configuration type, the first test data is transparently transmitted.

[0023] Optionally, transmitting the first target data to the device under test through the second protocol interface and determining a downlink data test result includes:

[0024] Detecting a downlink command sent by the host computer, transmitting the first target data in a preset downlink buffer area to the device under test through the second protocol interface;

[0025] Obtain the data receiving status of the device under test and determine the downlink data test result.

[0026] Optionally, in response to the second protocol interface receiving the uplink data sent by the device under test, parsing the uplink data by the test end to determine the second target data to be transmitted includes:

[0027] In response to the second protocol interface receiving the uplink data sent by the device under test, storing the uplink data in the test end; wherein the uplink data includes a custom command code and second test data;

[0028] Parsing the uplink data through the test end to obtain a custom command code and second test data in the uplink data;

[0029] The custom command code is used to determine the data type corresponding to the uplink data; wherein the data type includes an address allocation command type and a standard command type;

[0030] If the data type corresponding to the uplink data is a standard command type, the second test data is determined as the second target data to be transmitted to the host computer.

[0031] Optionally, the method of using the custom command code to determine a data type corresponding to the uplink data; wherein the data type includes an address allocation command type and a standard command type, and further includes:

[0032] If the data type corresponding to the uplink data is an address allocation command type, the bus device address corresponding to the test end is sent to the host computer end;

[0033] If the data type corresponding to the uplink data does not satisfy the address allocation command type and the standard command type, the second test data is transparently transmitted.

[0034] Optionally, transmitting the second target data to the host computer through the first protocol interface and determining an uplink data test result includes:

[0035] Pre-storing the second target data in a preset uplink buffer area;

[0036] Detecting an uplink command sent by the host computer, transmitting the second target data in a preset uplink buffer area to the host computer through the first protocol interface;

[0037] Obtain the data receiving status of the host computer and determine the uplink data test result.

[0038] According to a second aspect of the present invention, a bus device test device is provided, which is applied to a bus device test system, wherein the system comprises a host computer end, a test end and a device under test end, wherein the test end is configured with a first protocol interface and a second protocol interface, wherein the test end is connected to the host computer end via the first protocol interface, and is connected to the device under test end via the second protocol interface, wherein the device comprises:

[0039] A downlink data determination module, configured to, in response to the first protocol interface receiving downlink data sent by the host computer, parse the downlink data through the test terminal to determine first target data to be transmitted;

[0040] A downlink test module, used to transmit the first target data to the device under test through the second protocol interface, and determine a downlink data test result;

[0041] an uplink data determination module, configured to, in response to receiving the uplink data sent by the device under test through the second protocol interface, parse the uplink data through the test end to determine the second target data to be transmitted;

[0042] An uplink test module is used to transmit the second target data to the host computer through the first protocol interface and determine the uplink data test result.

[0043] According to another aspect of the present invention, a bus device test system is provided, the bus device test system comprises a host computer end, a test end and a device under test end, the test end is configured with a first protocol interface and a second protocol interface, the test end is connected to the host computer end through the first protocol interface, and is connected to the device under test end through the second protocol interface, the system comprises:

[0044] The host computer end is used to send downlink data to the first protocol interface of the test end, and receive uplink data sent by the device under test end transmitted by the first protocol interface;

[0045] The test end is used for, in response to the first protocol interface receiving downlink data sent by the host computer end, parsing the downlink data through the test end to determine the first target data to be transmitted; transmitting the first target data to the device under test end through the second protocol interface, and determining the downlink data test result; in response to the second protocol interface receiving uplink data sent by the device under test end, parsing the uplink data through the test end to determine the second target data to be transmitted; transmitting the second target data to the host computer end through the first protocol interface, and determining the uplink data test result;

[0046] The device under test end is used to send uplink data to the second protocol interface of the test end, and receive downlink data sent by the host computer end via the first protocol interface.

[0047] The bus device testing method provided by the embodiment of the present invention is applied to a bus device testing system, wherein the system includes a host computer end, a test end and a device under test end, wherein the test end is connected to the host computer end through a first protocol interface, and is connected to the device under test end through a second protocol interface. In response to receiving downlink data sent by the host computer end through the first protocol interface, the test end parses the downlink data to determine first target data to be transmitted, transmits the first target data to the device under test end through the second protocol interface, and determines a downlink data test result. In response to receiving uplink data sent by the device under test end through the second protocol interface, the test end parses the uplink data to determine second target data to be transmitted, transmits the second target data to the host computer end through the first protocol interface, and determines an uplink data test result. The host computer of the embodiment of the present invention is directly connected to the test end through the first protocol interface, and the test end is mounted on the I3C bus through the second protocol interface. The test end is used to enable the host computer to send and receive data to the bus device to be tested on the bus to test and verify the bus device, thereby realizing online communication between the general host computer and the I3C device, efficiently completing the test, greatly simplifying the test process of the bus device, and further improving the test efficiency.

[0048] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present invention. Moreover, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0050] Figure 1 is a flowchart of the steps of a bus device testing method provided by an embodiment of the present invention;

[0051] Figure 2 yes Figure 1 A flowchart of step 101 in the bus device testing method provided by an embodiment of the present invention;

[0052] Figure 3 yes Figure 1 A flowchart of step 102 in the bus device testing method provided by an embodiment of the present invention;

[0053] Figure 4 yes Figure 1 A flowchart of step 103 in the bus device testing method provided by an embodiment of the present invention;

[0054] Figure 5 yes Figure 1 A flowchart of step 104 in the bus device testing method provided by an embodiment of the present invention;

[0055] Figure 6 This is a process of a bus device testing method provided by an embodiment of the present invention Figure 1 ;

[0056] Figure 7 This is a process of a bus device testing method provided by an embodiment of the present invention Figure 2 ;

[0057] Figure 8 A bus device testing method provided by an embodiment of the present invention is shown in FIG. Figure 1 ;

[0058] Fig. 9 A bus device testing method provided by an embodiment of the present invention is shown in FIG. Figure 2 ;

[0059] Fig.10It is a structural schematic diagram of a bus device testing device provided by an embodiment of the present invention;

[0060] Fig.11 It is a structural schematic diagram of a bus device testing system provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0061] To make the purpose, technical scheme and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings. However, it will be appreciated by those skilled in the art that in the embodiments of the present invention, many technical details are proposed in order to enable the reader to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical scheme claimed in the present application can be implemented. The division of the following embodiments is for the convenience of description, and should not constitute any limitation on the specific implementation of the present invention. The various embodiments can be combined and referenced with each other without contradiction.

[0062] Reference Figure 1 , shows a flowchart of the steps of the bus device testing method provided by an embodiment of the present invention, which is applied to a bus device testing system, the system includes a host computer end, a test end and a device end to be tested, the test end is configured with a first protocol interface and a second protocol interface, the test end is connected to the host computer end through the first protocol interface, and is connected to the device end to be tested through the second protocol interface, the method may include:

[0063] Step 101, in response to the first protocol interface receiving downlink data sent by the host computer end, the test end parses the downlink data to determine the first target data to be transmitted.

[0064] In the embodiment of the present invention, in order to realize the communication between the general PC and the I3C device, the present embodiment uses the test end to perform data conversion. The test end needs to have the ability to communicate with both the PC and the I3C devices, as well as the ability of protocol conversion, that is, the test end is configured with a first protocol interface and a second protocol interface. Specifically, the test end is connected to the host computer end through the first protocol interface, and is connected to the device end under test through the second protocol interface. Specifically, the test end needs to include three parts: a PC interface, a protocol conversion module, and an I3C interface. The PC interface is used to directly connect to the PC, the protocol conversion module performs conversion of the two protocols, and the I3C interface is used to mount the device on the I3C bus. The present embodiment constructs two data paths for data uplink and data downlink, respectively realizing communication tests of data being uploaded from the I3C device to the PC and sent from the PC to the I3C device.

[0065] It should be noted that in this embodiment, the user can add a custom function module in the two data paths to realize the configuration of the test end, the standard CCC command code test of the I3C device, the sending of user-defined data packets and other functions. After that, the PC will be connected to the test end and mounted on the I3C bus as an I3C device. At this time, the PC has the ability to communicate and verify with other I3C devices, which will not be described in detail here.

[0066] Specifically, the system responds to the first protocol interface receiving the downlink data sent by the upper computer end, parses the downlink data through the test end, determines the first target data to be transmitted, and generates the downlink data in advance through the upper computer end; wherein, the downlink data includes a custom command code and a first test data, the custom command code is a user-defined command code for identifying the data type, the custom command code includes user-defined special characters to form different data type flags, and the first test data is the test data sent by the upper computer end to the bus device, which will not be described one by one here.

[0067] Specifically, the system responds to the first protocol interface receiving downlink data sent by the upper computer, stores the downlink data to the test end, parses the downlink data through the test end, obtains the custom command code and the first test data in the downlink data, and uses the custom command code to determine the data type corresponding to the downlink data; wherein, the data type includes a command type and a configuration type. If the data type corresponding to the downlink data is a command type, the first test data is determined as the first target data to be transmitted to the device under test.

[0068] In this embodiment, the test board is an instantiation of the test end in the test method, and is mainly composed of three parts: MCU minimum system, UART to USB peripheral circuit, and I3C peripheral circuit. The core of the test board is MCU, which needs to support both UART protocol and I3C protocol, and is mainly used to convert UART protocol and I3C protocol to each other. When using MCU, it is necessary to build the MCU minimum system, that is, MCU, power supply, clock, and reset circuit, which is the minimum requirement for the MCU to work normally.

[0069] Specifically, the signal lines required for the on-chip peripherals UART and I3C of the MCU are led out, where the UART signal line is led to the UART to USB peripheral circuit, and the I3C signal line is led to the I3C peripheral circuit. The MCU's UART uses TTL level and generally has only two lines, RX and TX, and cannot be directly connected to the PC. Therefore, the UART peripheral circuit is responsible for converting the UART protocol to the USB protocol that can be directly connected to the PC. There are many conversion schemes. The most commonly used one is to use the CH340 chip, which is a classic serial port to USB chip that can be used for UART to USB. The circuit is simple and stable, and the driver software is very convenient to install. It can be used as the first choice for the conversion circuit. In addition, the I3C peripheral circuit is a simple pull-up resistor circuit. Since I3C is compatible with I2C devices, I2C devices must have pull-up resistors when working, and the SDA line of I3C can also be switched between push-pull and open-drain modes. Pull-up resistors must exist when open-drain. Therefore, when it is impossible to ensure that the bus has pull-up resistors, it is necessary to retain pull-up resistors on the test board. In order to make the test board compatible with the bus with pull-up resistors, jumper caps are specially left on the test board, which can selectively connect or disconnect certain pull-up resistors. I will not go into details here.

[0070] It should be noted that the test end, i.e. the test board, plays the role of the intermediate computer and is used as the protocol transfer hardware between the PC and the verified I3C device. The test board is based on the MCU, which needs to support both the I3C protocol and the UART protocol, such as STM32H562xx or STM32H563xx, etc., including but not limited to these two series of chips. On the basis of the minimum system of the single-chip microcomputer, a UART-to-USB peripheral circuit is added to support the UART communication between the test board and the host computer control communication system. Since it is uncertain whether the MCU's IO port has a built-in pull-up resistor, a pull-up resistor is added to the I3C peripheral circuit of the test board and connected with a jumper cap, which can provide pull-up in the absence of a pull-up resistor, and disconnect the external pull-up in the presence of a pull-up resistor to ensure the transmission rate.

[0071] Specifically, refer to Figure 8 , showing a schematic diagram of a bus device testing method provided by an embodiment of the present invention Figure 1, which is the data flow control structure during data downlink. Based on the characteristics and functions of I3C, the functional definition of data downlink is given, including changing the relevant configuration of the intermediate module, sending the standard I3C CCC command, and sending transparent data. Based on the user-defined command system, different data flows can be realized. Among them, the functional modules that flow through during the data downlink process include: PC interface, protocol conversion module, I3C interface according to the direction of data flow. The protocol conversion module includes PC downlink data buffer, PC data parsing, module configuration storage area, built-in command storage area, and I3C downlink data buffer during the downlink process.

[0072] Specifically, first, the user can customize a unique set of data formats or command codes and store them in the PC data parsing module. The PC downlink data buffer is responsible for temporarily storing data from the PC interface. The PC data parsing will determine the data type of this parsing based on the user-defined command code. The data that meets the command type will extract key information and transfer it to the built-in command storage area. The data that meets the configuration type will extract key information and transfer it to the module configuration storage area. The data that does not meet the requirements will be considered as data to be transparently transmitted and sent directly to the I3C data buffer. The built-in command storage area will correspond the user-defined command code to the standard CCC command code of I3C one by one, and select the command code according to the command code parsed from the PC data. The module configuration storage area stores register group configuration information of different modes, and the user-defined command code corresponds to this information one by one. According to the configuration selection value parsed from the UART data, the corresponding configuration is selected, and the configuration information is configured to the corresponding position of the intermediate module, which can realize the mode switching of the I3C peripherals, etc. The I3C downstream data buffer is responsible for temporarily storing the data to be sent through I3C. When a sendable command is received from the PC, the data in the I3C downstream data buffer is loaded into the I3C interface, and the interface will send this data to the I3C bus.

[0073] Step 102: Transmit the first target data to the device under test through the second protocol interface, and determine the downlink data test result.

[0074] In some embodiments, the definition example of the custom command code for data downlink, the user defines special characters as different data type flags, where CFG-X is the configuration selection flag, CMD-X is the command selection flag, EOF- is a sendable command, and the rest is transparent data. The user stores the configuration information in the form of a group in the module configuration storage area in advance, and stores the CCC command code to be sent in the built-in command storage area. When the user sends "CFG-1" to the test board through the host computer control communication system, it means that the user will select the first group of configuration information. At this time, the intermediate module will configure the module according to the information and end the communication with the PC after the configuration is completed. When the user sends "CMD-3" to the test board through the host computer control communication system, it means that the user will select the third CCC command he pre-stored, and the intermediate module will put this CCC command into the I3C downlink data buffer; when the user sends other data except "EOF-", these data will be directly put into the I3C downlink data buffer in the form of transparent transmission. When the user sends "EOF-", it means that the data transmission of this PC is completed, and the I3C downstream data buffer will put all the saved data into the I3C interface, and the hardware will automatically send these data using the I3C protocol. In particular, for the "CMD-" type command selection process, it is not necessarily limited to the standard CCC command. Users can also save their frequently used data, IBI, etc. into the storage area, and use this command to achieve the purpose of sending a large amount of data with one click.

[0075] Step 103: In response to the second protocol interface receiving the uplink data sent by the device under test, the test end parses the uplink data to determine the second target data to be transmitted.

[0076] In the embodiment of the present invention, the system receives the uplink data sent by the device under test in response to the second protocol interface, analyzes the uplink data through the test end, determines the second target data to be transmitted, and specifically, based on the characteristics and functions of I3C, provides the function definition of data uplink, including reporting the dynamic address to the PC, uploading the standard I3C CCC command, and uploading transparent data. When the I3C interface of the intermediate module receives the data and sends it to the protocol conversion module, the conversion module can determine the type of data received according to the standard command header of the CCC command, thereby analyzing the data and uploading the data to the PC through the PC interface.

[0077] Reference Fig. 9 , showing a schematic diagram of a bus device testing method provided by an embodiment of the present invention Figure 2, which shows the data flow control structure during data uplink, including the functional modules that flow through during data uplink, including: I3C interface, protocol conversion module, PC interface according to the data flow direction, wherein the protocol conversion module includes I3C uplink data buffer, I3C data parsing, and PC uplink data buffer during the uplink process. The I3C uplink data buffer is used to store data from the I3C interface; the I3C data parsing parses the data from the buffer, judges the command according to the CCC standard command header, extracts the command code after confirming that it is a CCC command, and sends it to the PC uplink data buffer. If it is not a CCC command, it is directly transparently transmitted to the uplink data buffer; the PC uplink data buffer is used to temporarily store data to be sent to the PC interface.

[0078] Step 104, transmitting the second target data to the host computer through the first protocol interface, and determining the uplink data test result.

[0079] The bus device testing method provided by the embodiment of the present invention is applied to a bus device testing system, wherein the system includes a host computer end, a test end and a device under test end, wherein the test end is connected to the host computer end through a first protocol interface, and is connected to the device under test end through a second protocol interface. In response to receiving downlink data sent by the host computer end through the first protocol interface, the test end parses the downlink data to determine first target data to be transmitted, transmits the first target data to the device under test end through the second protocol interface, and determines a downlink data test result. In response to receiving uplink data sent by the device under test end through the second protocol interface, the test end parses the uplink data to determine second target data to be transmitted, transmits the second target data to the host computer end through the first protocol interface, and determines an uplink data test result. The host computer of the embodiment of the present invention is directly connected to the test end through the first protocol interface, and the test end is mounted on the I3C bus through the second protocol interface. The test end is used to enable the host computer to send and receive data to the bus device to be tested on the bus to test and verify the bus device, thereby realizing online communication between the general host computer and the I3C device, efficiently completing the test, greatly simplifying the test process of the bus device, and further improving the test efficiency.

[0080] Further, see Figure 2 , showing Figure 1 A flowchart of step 101 in a bus device testing method is provided. The method is substantially the same as the bus device testing method provided in the first embodiment of the present invention. Step 101 may include:

[0081] Step 201, generating downlink data in advance through the host computer; wherein the downlink data includes a custom command code and first test data.

[0082] Step 202: In response to the first protocol interface receiving the downlink data sent by the host computer, the downlink data is stored in the test terminal.

[0083] Step 203: parse the downlink data through the test end to obtain the custom command code and the first test data in the downlink data.

[0084] Step 204: Use the custom command code to determine the data type corresponding to the downlink data; wherein the data type includes a command type and a configuration type.

[0085] Step 205: If the data type corresponding to the downlink data is a command type, the first test data is determined as the first target data to be transmitted to the device under test.

[0086] It should be noted that in the above steps, the host computer generates downlink data, and the downlink data includes a custom command code and a first test data. The test end receives the downlink data sent by the host computer through the first protocol interface, and stores the received downlink data to the test end to ensure that the data is available at the test end for subsequent processing. The test end parses the stored downlink data, obtains the custom command code and the first test data in the downlink data, and uses the custom command code to determine the data type corresponding to the downlink data. The data type includes a command type and a configuration type, and different processing logic is performed according to the data type.

[0087] Specifically, if the data type corresponding to the downlink data is a command type, the first test data is determined as the first target data to be transmitted to the device under test, the upper computer generates the downlink data, and sends it to the test end through the first protocol interface, the test end receives and stores the downlink data to ensure data integrity and availability, the test end parses the downlink data, obtains key information (custom command code and first test data), determines the data type according to the custom command code, and determines the subsequent processing logic; if the data type is a command type, the first test data is determined as the first target data to be transmitted to the device under test.

[0088] In the embodiment of the present invention, the host computer sends data to the test board through the host computer control communication system, and these data are sent to the receiving register of the UART peripheral of the MCU through the UART to USB peripheral circuit. When there is data in the receiving register, the UART will raise an interrupt, and the CPU of the MCU will execute the program pre-set by the test board control communication system after receiving the interrupt signal, and store the data in the receiving register in the UART receiving data buffer. The UART data parsing system obtains the data sent by the PC from the buffer and parses it. According to the user-defined command code, the data type sent this time is confirmed. If it belongs to the MCU configuration command, the configuration selection value is sent to the MCU configuration storage area, and the configuration storage area will select the corresponding configuration information to modify the configuration of the register group of the MCU, and the data transmission ends here; if it belongs to the CCC command selection command, the command selection value will be sent to the built-in command storage area, and the built-in command storage area will select the corresponding CCC command according to the command selection value and send it to the I3C sending data buffer; if it does not belong to the above two types of data, it is considered to be the data to be transparently transmitted, so this batch of data is directly loaded into the I3C sending data buffer. When the UART data is parsed to a sendable command, the data in the I3C send data buffer will be sent to the I3C data send register, and the hardware will automatically send the data in the format of the I3C protocol, and the data transmission ends here.

[0089] Specifically, in step 205, if the data type corresponding to the downlink data is a command type, determining the first test data as the first target data to be transmitted to the device under test may specifically include the following steps:

[0090] First, the test end compares the custom command code with the general command code of the device under test to determine the target command corresponding to the custom command code;

[0091] Secondly, the target command and the first test data are determined as first target data to be transmitted to the device under test, and the first target data is stored in a preset downlink buffer area.

[0092] In this embodiment, the test end compares the custom command code with the general command code of the device under test, determines the target command corresponding to the custom command code, determines the target command and the first test data as the first target data to be transmitted to the device under test, and stores the first target data in a preset downlink buffer area to prepare for subsequent data transmission and ensure that the data is stored in the correct location before transmission.

[0093] Specifically, step 204 uses the custom command code to determine the data type corresponding to the downlink data; wherein the data type includes the command type and the configuration type, and may also include:

[0094] If the data type corresponding to the downlink data is a configuration type, modifying the configuration of the test end according to the first test data;

[0095] If the data type corresponding to the downlink data does not satisfy the command type and the configuration type, the first test data is transparently transmitted.

[0096] In this embodiment, if the data type corresponding to the downlink data is a configuration type, the test end is modified according to the first test data, and the configuration of the test end is dynamically adjusted according to the received data to adapt to different test requirements. If the data type corresponding to the downlink data does not meet the command type and the configuration type, the first test data is transparently transmitted to ensure that all types of data can be processed, even uncommon data types can be correctly transmitted. Specifically, the target command is determined by comparing the custom command code and the general command code, the target command and the first test data are combined into the first target data, and stored in the downlink buffer area. The configuration of the test end is modified according to the first test data to adapt to the specific test scenario. For data that does not meet the command type and the configuration type, it is directly transparently transmitted to ensure the integrity and availability of the data.

[0097] Further, see Figure 3 , showing Figure 1 A flowchart of step 102 in a bus device testing method is provided. The method is substantially the same as the bus device testing method provided in the first embodiment of the present invention. Step 102 may include:

[0098] Step 301: Detect a downlink command sent by a host computer, and transmit the first target data in a preset downlink buffer area to the device under test through a second protocol interface.

[0099] Step 302, obtaining the data receiving status of the device under test and determining the downlink data test result.

[0100] In this embodiment, after detecting the downlink command sent by the host computer, the first target data in the preset downlink buffer area is transmitted to the device under test through the second protocol interface, ensuring that the first target data can be accurately transmitted to the device under test for subsequent testing or operation. The data receiving state of the device under test is obtained, and the downlink data test result is determined. The data receiving state returned by the device under test is used to determine whether the data is successfully received, and the integrity and correctness of the data transmission are verified to ensure the accuracy of the test result. When the downlink command sent by the host computer is detected, the test end extracts the first target data from the preset downlink buffer area and sends it to the device under test through the second protocol interface. After receiving the data, the device under test returns a data receiving state, indicating whether the data is successfully received. The test end determines the result of the downlink data test based on this receiving state, thereby verifying the validity of the data transmission, ensuring the complete transmission of the data from the test end to the device under test, and verifying the transmission result through the feedback of the device under test.

[0101] Further, see Figure 4 , showing Figure 1 A flowchart of step 103 in a bus device testing method is provided. The method is substantially the same as the bus device testing method provided in the first embodiment of the present invention. Step 103 may include:

[0102] Step 401, in response to the second protocol interface receiving uplink data sent by the device under test, storing the uplink data in the test end; wherein the uplink data includes a custom command code and second test data.

[0103] Step 402: parse the uplink data through the test end to obtain the custom command code and the second test data in the uplink data.

[0104] Step 403: Use the custom command code to determine the data type corresponding to the uplink data; wherein the data type includes an address allocation command type and a standard command type.

[0105] Step 404: If the data type corresponding to the uplink data is a standard command type, the second test data is determined as the second target data to be transmitted to the host computer.

[0106] In this embodiment, in response to the second protocol interface receiving the uplink data sent by the device under test, the uplink data is stored in the test end, wherein the uplink data includes a custom command code and a second test data, ensuring that the uplink data is available at the test end for subsequent processing. The stored uplink data is parsed by the test end to obtain the custom command code and the second test data in the uplink data, and the custom command code is used to determine the data type corresponding to the uplink data, the data type includes an address allocation command type and a standard command type, so that different processing logics are performed according to the data type. If the data type corresponding to the uplink data is a standard command type, the second test data is determined as the second target data to be transmitted to the host computer end. The test end receives the uplink data sent by the device under test through the second protocol interface and stores it in the test end. The test end parses the uplink data to obtain key information (custom command code and second test data), determines the data type corresponding to the uplink data according to the custom command code, and determines the subsequent processing logic. If the data type is a standard command type, the second test data is determined as the second target data to be transmitted to the host computer end.

[0107] Specifically, step 403 uses the custom command code to determine the data type corresponding to the uplink data; wherein the data type includes the address allocation command type and the standard command type, and further includes:

[0108] If the data type corresponding to the uplink data is an address allocation command type, the bus device address corresponding to the test end is sent to the host computer end;

[0109] If the data type corresponding to the uplink data does not satisfy the address allocation command type and the standard command type, the second test data is transparently transmitted.

[0110] It should be noted that if the data type corresponding to the uplink data is the address allocation command type, the bus device address corresponding to the test end is sent to the host computer end to ensure that the host computer end can obtain the bus device address corresponding to the test end in order to perform address allocation or related operations. If the data type corresponding to the uplink data does not meet the address allocation command type and the standard command type, the second test data is transparently transmitted to ensure that all types of data can be processed, even uncommon data types can be correctly transmitted. When the data type corresponding to the uplink data is the address allocation command type, the test end sends its own bus device address to the host computer end. For data that does not meet the address allocation command type and the standard command type, the test end directly transparently transmits.

[0111] Further, see Figure 5 , showing Figure 1A flowchart of step 104 in a bus device testing method is provided. The method is substantially the same as the bus device testing method provided in the first embodiment of the present invention. Step 104 may include:

[0112] Step 501: Pre-store second target data in a preset uplink buffer area.

[0113] Step 502: Detect an uplink command sent by the host computer, and transmit the second target data in the preset uplink buffer area to the host computer through the first protocol interface.

[0114] Step 503, obtaining the data receiving status of the host computer and determining the uplink data test result.

[0115] In this embodiment, the second target data is stored in a preset uplink buffer area in advance, and after detecting the uplink command sent by the host computer, the second target data in the preset uplink buffer area is transmitted to the host computer through the first protocol interface, ensuring that the second target data can be accurately transmitted to the host computer for subsequent analysis or operation. The data reception status of the host computer is obtained, and the uplink data test result is determined. Whether the data is successfully received is determined by the data reception status returned by the host computer, and the integrity and correctness of the data transmission are verified to ensure the accuracy of the test result.

[0116] Specifically, the second target data is stored in a preset uplink buffer area in advance to ensure that the data is stored in the correct position before transmission. When an uplink command sent by the host computer is detected, the test end extracts the second target data from the preset uplink buffer area and sends it to the host computer through the first protocol interface. After receiving the data, the host computer returns a data reception status to indicate whether the data is successfully received. The test end determines the result of the uplink data test based on this reception status, thereby verifying the validity of the data transmission.

[0117] In some embodiments, in order to facilitate those skilled in the art to fully understand the above bus device testing method, refer to Figure 6 , which shows the process of a bus device testing method provided by an embodiment of the present invention Figure 1 , showing the overall process of data uplink of the bus device test provided by an embodiment of the present invention, the method may include:

[0118] S601, the host computer sends data to the test end, and the test end processes and forwards it to the UART peripheral of the MCU;

[0119] S602, the test end controls the communication module to receive data from the UART peripheral and stores it in a buffer;

[0120] S603, the UART data parsing module obtains data from the buffer;

[0121] S604, the UART data analysis module analyzes the data;

[0122] S605, determining whether the data is for selecting MCU configuration;

[0123] S606, determining whether the data is a selection command;

[0124] S607, obtaining configuration information from the MCU configuration storage area and modifying the MCU register configuration;

[0125] S608, obtaining a command from the built-in command storage area and sending it to the I3C data buffer area;

[0126] S609, transparently transmit the data to the I3C data buffer area;

[0127] S610, UART receives the send command

[0128] S611, the I3C data buffer sends data through the I3C send register.

[0129] It should be noted that in the above steps, the host computer sends data to the test board through the host computer control communication system, and these data are sent to the receiving register of the UART peripheral of the MCU through the UART to USB peripheral circuit. When there is data in the receiving register, the UART will raise an interrupt, and the CPU of the MCU will execute the program pre-set by the test board control communication system after receiving the interrupt signal, and store the data in the receiving register in the UART receiving data buffer. The UART data parsing system obtains the data sent by the PC from the buffer and parses it. According to the user-defined command code, it confirms the data type sent this time. If it belongs to the MCU configuration command, the configuration selection value is sent to the MCU configuration storage area, and the configuration storage area will select the corresponding configuration information to modify the configuration of the MCU register group, and this data transmission ends here; if it belongs to the CCC command selection command, the command selection value will be sent to the built-in command storage area, and the built-in command storage area will select the corresponding CCC command according to the command selection value and send it to the I3C sending data buffer; if it does not belong to the above two types of data, it is considered to be the data to be transparently transmitted, so this batch of data is directly loaded into the I3C sending data buffer. Specifically, when the UART data is parsed to a sendable command, the data in the I3C send data buffer will be sent to the I3C data send register, and the hardware will automatically send the data in the format of the I3C protocol, and the data transmission ends here.

[0130] In some embodiments, in order to facilitate those skilled in the art to fully understand the above bus device testing method, refer to Figure 7, which shows the process of a bus device testing method provided by an embodiment of the present invention Figure 2 , shows the overall process of data downlink of the bus device test provided by an embodiment of the present invention, and the method may include:

[0131] S701, the test end receives data sent by the I3C device;

[0132] S702, the test end controls the communication module to receive data from the I3C device and stores it in a buffer;

[0133] S703, the I3C data parsing module obtains data from the buffer;

[0134] S704, the I3C data analysis module analyzes the data;

[0135] S705, determining whether the data is dynamically allocated;

[0136] S706, determining whether the data is a CCC command;

[0137] S707, sending from the allocated address to the UART data buffer;

[0138] S708, sending the CCC command to the UART data buffer;

[0139] S709, transparently transmit the data to the UART data buffer area;

[0140] S710, UART receives a send command;

[0141] S711, the UART data buffer sends data through the UART transmit register.

[0142] It should be noted that in the above steps, the test board detects that there is data sent from the I3C bus. When the test board can respond to the data, it will receive the data on the I3C bus. These data will be stored in the I3C receiving register. The I3C receiving data buffer will take out the data in the register, and then the I3C command parsing system will parse these commands. Because the CCC command of I3C has a standard command format, it is only necessary to simply determine whether this command is in the standard command format to confirm the command type of this time. If this command is a dynamic address allocation command, the I3C dynamic address of this test board is sent to the UART sending data buffer; if this command is a CCC standard command, the CCC command code is extracted according to the command format and sent to the UART sending data buffer; otherwise, this command is sent to the UART sending data buffer as the data that needs to be transparently transmitted. When the communication end signal is transmitted on the I3C bus, the UART buffer data is sent to the hardware UART sending register, and the hardware UART will automatically send data outward, and the data is upstream to the PC via the UART to USB circuit.

[0143] Reference Fig.10 , shows a schematic diagram of the structure of a bus device test device provided by an embodiment of the present invention, which is applied to a bus device test system, the system includes a host computer end, a test end and a device end to be tested, the test end is configured with a first protocol interface and a second protocol interface, the test end is connected to the host computer end through the first protocol interface, and is connected to the device end to be tested through the second protocol interface, the device includes:

[0144] A downlink data determination module 801 is used to determine first target data to be transmitted by parsing the downlink data sent by the host computer end through the test end in response to the first protocol interface receiving the downlink data sent by the host computer end;

[0145] A downlink test module 802, configured to transmit the first target data to the device under test through the second protocol interface, and determine a downlink data test result;

[0146] An uplink data determination module 803 is configured to, in response to receiving uplink data sent by the device under test through the second protocol interface, parse the uplink data through the test end to determine second target data to be transmitted;

[0147] The uplink test module 804 is used to transmit the second target data to the host computer through the first protocol interface and determine the uplink data test result.

[0148] Further, the downlink data determination module 801 is specifically configured as follows:

[0149] A generating submodule, used to generate downlink data in advance through the host computer; wherein the downlink data includes a custom command code and first test data;

[0150] A first storage submodule, configured to store the downlink data in the test end in response to the first protocol interface receiving the downlink data sent by the host computer end;

[0151] A first parsing submodule, configured to parse the downlink data through the test end to obtain a custom command code and first test data in the downlink data;

[0152] A first judgment submodule, configured to use the custom command code to judge the data type corresponding to the downlink data; wherein the data type includes a command type and a configuration type;

[0153] The first determining submodule is used to determine the first test data as the first target data to be transmitted to the device under test if the data type corresponding to the downlink data is a command type.

[0154] Furthermore, the first determining submodule includes:

[0155] A comparison unit, configured to compare the custom command code with a universal command code of the device under test through the test end, and determine a target command corresponding to the custom command code;

[0156] The storage unit is used to determine the target command and the first test data as first target data to be transmitted to the device under test, and store the first target data in a preset downlink buffer area.

[0157] Furthermore, the downlink data determination module 801 further includes:

[0158] a modification submodule, configured to modify the configuration of the test end according to the first test data if the data type corresponding to the downlink data is a configuration type;

[0159] The first transparent transmission submodule is used to transparently transmit the first test data if the data type corresponding to the downlink data does not meet the command type and the configuration type.

[0160] Furthermore, the downlink test module 802 includes:

[0161] A first transmission submodule, configured to detect a downlink command sent by the host computer, and transmit the first target data in a preset downlink buffer area to the device under test through the second protocol interface;

[0162] The first acquisition submodule is used to obtain the data receiving status of the device under test and determine the downlink data test result.

[0163] Further, the uplink data determination module 803 includes:

[0164] A second storage submodule, configured to store the uplink data to the test end in response to the second protocol interface receiving the uplink data sent by the device under test; wherein the uplink data includes a custom command code and second test data;

[0165] A second parsing submodule, configured to parse the uplink data through the test end to obtain a custom command code and second test data in the uplink data;

[0166] A second judgment submodule is used to use the custom command code to judge the data type corresponding to the uplink data; wherein the data type includes an address allocation command type and a standard command type;

[0167] The second determination submodule is used to determine the second test data as the second target data to be transmitted to the host computer end if the data type corresponding to the uplink data is a standard command type.

[0168] Furthermore, the uplink data determination module 803 further includes:

[0169] A sending submodule, used for sending the bus device address corresponding to the test end to the host computer end if the data type corresponding to the uplink data is an address allocation command type;

[0170] The second transparent transmission submodule is used to transparently transmit the second test data if the data type corresponding to the uplink data does not meet the address allocation command type and the standard command type.

[0171] Furthermore, the uplink test module 804 includes:

[0172] A third storage submodule, used for pre-storing the second target data into a preset uplink buffer area;

[0173] A second transmission submodule, configured to detect an uplink command sent by the host computer, and transmit the second target data in a preset uplink buffer area to the host computer through the first protocol interface;

[0174] The second acquisition submodule is used to obtain the data receiving status of the host computer and determine the uplink data test result.

[0175] The bus device testing device provided in an embodiment of the present invention is applied to a bus device testing system. The system includes a host computer end, a test end and a device under test end. The test end is connected to the host computer end through a first protocol interface, and is connected to the device under test end through a second protocol interface. In response to receiving downlink data sent by the host computer end through the first protocol interface, the test end parses the downlink data to determine first target data to be transmitted, transmits the first target data to the device under test end through the second protocol interface, and determines a downlink data test result. In response to receiving uplink data sent by the device under test end through the second protocol interface, the test end parses the uplink data to determine second target data to be transmitted, transmits the second target data to the host computer end through the first protocol interface, and determines an uplink data test result. The host computer of the embodiment of the present invention is directly connected to the test end through the first protocol interface, and the test end is mounted on the I3C bus through the second protocol interface. The test end is used to enable the host computer to send and receive data to the bus device to be tested on the bus to test and verify the bus device, thereby realizing online communication between the general host computer and the I3C device, efficiently completing the test, greatly simplifying the test process of the bus device, and further improving the test efficiency.

[0176] Reference Fig.11 The embodiment of the present invention further provides a bus device test system, the bus device test system includes a host computer end, a test end and a device end to be tested, the test end is configured with a first protocol interface and a second protocol interface, the test end is connected to the host computer end through the first protocol interface, and is connected to the device end to be tested through the second protocol interface, the system includes:

[0177] The host computer end is used to send downlink data to the first protocol interface of the test end, and receive uplink data sent by the device under test end transmitted by the first protocol interface;

[0178] The test end is used for, in response to the first protocol interface receiving downlink data sent by the host computer end, parsing the downlink data through the test end to determine the first target data to be transmitted; transmitting the first target data to the device under test end through the second protocol interface, and determining the downlink data test result; in response to the second protocol interface receiving uplink data sent by the device under test end, parsing the uplink data through the test end to determine the second target data to be transmitted; transmitting the second target data to the host computer end through the first protocol interface, and determining the uplink data test result;

[0179] The device under test end is used to send uplink data to the second protocol interface of the test end, and receive downlink data sent by the host computer end via the first protocol interface.

[0180] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0181] Each embodiment in this specification is described in a related manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0182] The above description is only a preferred embodiment of the present invention and is not intended to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims

1. A bus device testing method, characterized in that: Applied to a bus device test system, the system includes a host computer end, a test end and a device end to be tested, the test end is configured with a first protocol interface and a second protocol interface, the test end is connected to the host computer end through the first protocol interface, and is connected to the device end to be tested through the second protocol interface, the method includes: In response to the first protocol interface receiving the downlink data sent by the host computer end, the test end parses the downlink data to determine the first target data to be transmitted; Transmitting the first target data to the device under test through the second protocol interface, and determining a downlink data test result; In response to the second protocol interface receiving the uplink data sent by the device under test, the test end parses the uplink data to determine the second target data to be transmitted; The second target data is transmitted to the host computer through the first protocol interface, and an uplink data test result is determined.

2. The method according to claim 1, characterized in that: The step of: in response to the first protocol interface receiving the downlink data sent by the host computer, parsing the downlink data by the test end to determine the first target data to be transmitted includes: Generate downlink data in advance through the host computer; wherein the downlink data includes a custom command code and first test data; In response to the first protocol interface receiving the downlink data sent by the host computer, storing the downlink data in the test terminal; Parsing the downlink data through the test end to obtain a custom command code and first test data in the downlink data; The custom command code is used to determine the data type corresponding to the downlink data; wherein the data type includes a command type and a configuration type; If the data type corresponding to the downlink data is a command type, the first test data is determined as the first target data to be transmitted to the device under test.

3. The method according to claim 2, characterized in that If the data type corresponding to the downlink data is a command type, determining the first test data as first target data to be transmitted to the device under test includes: The test end compares the custom command code with the general command code of the device under test to determine the target command corresponding to the custom command code; The target command and the first test data are determined as first target data to be transmitted to the device under test, and the first target data is stored in a preset downlink buffer area.

4. The method according to claim 2, characterized in that: The method of using the custom command code to determine the data type corresponding to the downlink data; wherein the data type includes a command type and a configuration type, and further includes: If the data type corresponding to the downlink data is a configuration type, modifying the configuration of the test end according to the first test data; If the data type corresponding to the downlink data does not satisfy the command type and the configuration type, the first test data is transparently transmitted.

5. The method according to claim 1, characterized in that The step of transmitting the first target data to the device under test through the second protocol interface and determining a downlink data test result includes: Detecting a downlink command sent by the host computer, transmitting the first target data in a preset downlink buffer area to the device under test through the second protocol interface; Obtain the data receiving status of the device under test and determine the downlink data test result.

6. The method according to claim 1, characterized in that The step of, in response to the second protocol interface receiving the uplink data sent by the device under test, parsing the uplink data by the test end to determine the second target data to be transmitted, includes: In response to the second protocol interface receiving the uplink data sent by the device under test, storing the uplink data in the test end; wherein the uplink data includes a custom command code and second test data; Parsing the uplink data through the test end to obtain a custom command code and second test data in the uplink data; The custom command code is used to determine the data type corresponding to the uplink data; wherein the data type includes an address allocation command type and a standard command type; If the data type corresponding to the uplink data is a standard command type, the second test data is determined as the second target data to be transmitted to the host computer.

7. The method according to claim 6, characterized in that The method of using the custom command code to determine the data type corresponding to the uplink data; wherein the data type includes an address allocation command type and a standard command type, and further includes: If the data type corresponding to the uplink data is an address allocation command type, the bus device address corresponding to the test end is sent to the host computer end; If the data type corresponding to the uplink data does not satisfy the address allocation command type and the standard command type, the second test data is transparently transmitted.

8. The method according to claim 1, characterized in that The transmitting the second target data to the host computer through the first protocol interface and determining the uplink data test result includes: Pre-storing the second target data in a preset uplink buffer area; Detecting an uplink command sent by the host computer, transmitting the second target data in a preset uplink buffer area to the host computer through the first protocol interface; Obtain the data receiving status of the host computer and determine the uplink data test result.

9. A bus device testing device, characterized in that: Applied to a bus device test system, the system includes a host computer end, a test end and a device under test end, the test end is configured with a first protocol interface and a second protocol interface, the test end is connected to the host computer end through the first protocol interface, and is connected to the device under test end through the second protocol interface, the device includes: A downlink data determination module, configured to, in response to the first protocol interface receiving downlink data sent by the host computer, parse the downlink data through the test terminal to determine first target data to be transmitted; A downlink test module, used to transmit the first target data to the device under test through the second protocol interface, and determine a downlink data test result; an uplink data determination module, configured to, in response to receiving the uplink data sent by the device under test through the second protocol interface, parse the uplink data through the test end to determine the second target data to be transmitted; An uplink test module is used to transmit the second target data to the host computer through the first protocol interface and determine the uplink data test result.

10. A bus device testing system, characterized in that: The bus device test system includes a host computer end, a test end and a device under test end, wherein the test end is configured with a first protocol interface and a second protocol interface, the test end is connected to the host computer end through the first protocol interface, and is connected to the device under test end through the second protocol interface, and the system includes: The host computer end is used to send downlink data to the first protocol interface of the test end, and receive uplink data sent by the device under test end transmitted by the first protocol interface; The test end is used for, in response to the first protocol interface receiving downlink data sent by the host computer end, parsing the downlink data through the test end to determine the first target data to be transmitted; transmitting the first target data to the device under test end through the second protocol interface, and determining the downlink data test result; in response to the second protocol interface receiving uplink data sent by the device under test end, parsing the uplink data through the test end to determine the second target data to be transmitted; transmitting the second target data to the host computer end through the first protocol interface, and determining the uplink data test result; The device under test end is used to send uplink data to the second protocol interface of the test end, and receive downlink data sent by the host computer end via the first protocol interface.