An embedded product hardware testing system and method based on interface configuration

Abstract

The present invention relates to embedded product hardware testing technology, and discloses an embedded product hardware testing system and method based on interface configuration, which does not require software personnel to cooperate with hardware testing to perform temporary software modification, thereby eliminating exceptions caused by software logic and processing errors, ensuring the correctness and reliability of test results, and improving test efficiency. The method includes: establishing two-way communication between a test device and a tested product; a user selects a hardware interface of a tested product on the test device for configuration; the test device automatically generates an application execution file according to the user configuration content and sends it to the tested product; the tested product completes the configuration of the corresponding hardware interface; the user selects a successfully configured hardware interface of the tested product on the test device and sets test parameters; the test device automatically generates a test instruction and sends it to the tested product; the tested product controls the corresponding hardware interface according to the test instruction, and feeds back execution status information to the test device; the test device records and analyzes the data fed back by the tested product to generate a test result.

Description

Technical Field

[0001] The invention relates to an embedded product hardware testing technology, and in particular to an embedded product hardware testing system and method based on interface configuration. Background Art

[0002] At present, the new energy industry is in a stage of rapid development, and the power supply system has become the protagonist in the process of accelerating innovation in the new energy industry. The management and control module of the power supply system is one of the core components of the power supply system products. It is undoubtedly the core control unit of the power supply system. It is responsible for the management of the battery status of the entire system. By obtaining real-time parameters and status information during the operation of the power supply system, the power supply system is detected and fault diagnosed. It has external communication transmission and system control functions, and ensures the normal operation of the power supply system through early warning, external control and other means. Since the power supply system is composed of battery modules and control modules, and the battery cell materials and module models are diverse, the structure of the power supply system and the energy storage and power supply requirements will vary according to user needs. The design of the power supply system must meet the requirements of different usage scenarios, comprehensive structure, space, data, security and other requirements, and the hardware of the required embedded management and control module is also more customized and diversified.

[0003] Although there are many types of microprocessors that can be used in embedded products, enterprises generally choose several common models. For enterprises, the purpose of choosing commonly used common models is to establish a relatively stable and reusable technology platform, reduce the cost of embedded product development, and ensure reliability and safety. However, due to the limitations of product structure, components, circuit boards, and functional requirements, it is difficult to standardize hardware design. Based on the same chip platform, multiple models of products are derived at the application layer. The functions of these products are similar. The main difference is that the port definitions of the main chip used in the hardware design are different, and the peripheral conditioning circuits and component models are different. Therefore, for embedded products on the same development platform, it is necessary to find a universal testing method and system that can quickly and efficiently complete the debugging and testing of hardware functions and component performance during product hardware-level testing.

[0004] In the development process of embedded products, the development and testing of any model product requires the completion of functional and performance tests covering both software and hardware. The testing work of embedded products mainly includes hardware-level testing, software logic testing, system qualification testing, etc. Among them, the hardware circuit board running embedded software is also called a "logic control board". For the hardware board-level testing of the logic control board, the traditional operation is completed by software developers in cooperation with and assistance to hardware designers. Specifically, software personnel complete the interface configuration in the software based on the hardware circuit design interface to ensure the consistency of hardware and software interface design, and cooperate with hardware personnel to design simple logic control programs to support the functional debugging and performance testing of the logic control board.

[0005] Usually, various abnormal situations may occur during the hardware debugging process, and the reasons include: unreasonable hardware circuit design, production process problems, different performance of component batches, missing components, mismatched software program configuration, software logic processing errors, etc. In most cases, the process of hardware board-level testing and debugging of embedded products often takes a long time, and in the hardware board-level testing stage, the simultaneous participation of software and hardware will increase the probability of abnormalities. The simultaneous existence of software and hardware problems makes it more difficult to troubleshoot problems, and hardware problems themselves cannot be exposed in time. Summary of the invention

[0006] The technical problem to be solved by the present invention is to propose an embedded product hardware testing system and method based on interface configuration, which does not require software personnel to cooperate with hardware testing to make temporary software modifications, thereby eliminating anomalies caused by software logic and processing errors, ensuring the correctness and reliability of test results, and improving test efficiency.

[0007] The technical solution adopted by the present invention to solve the above technical problems is:

[0008] On the one hand, the present invention provides an embedded product hardware testing system based on interface configuration, comprising a product under test and a testing device; the product under test and the testing device are connected via a communication line;

[0009] The test device includes a display and operation unit, an interface configuration unit, a communication unit, a storage unit and a logic processing control unit;

[0010] The display and operation unit is used to display the relevant information of the interface configuration, including the configuration interface type and interface-related parameter characteristics for the user to view and select; during the user's interface configuration process of the tested product, provide real-time information prompts and display the configuration status and configuration results; and to set the display and operation of the test parameters and display the test status of the tested product;

[0011] The interface configuration unit is used to update the stored initial application source code of the corresponding hardware interface of the tested product according to the configuration operation of the user on the display and operation unit, and call the integrated development compilation environment to generate the application execution file;

[0012] The communication unit is used for two-way data communication between the test device and the product under test;

[0013] The storage unit is used to store the initial application source code of each hardware interface of the tested product and the historical information of user operations;

[0014] The logic processing control unit is used to perform logic processing according to user operations and complete task scheduling of other functional units in the test device, including: displaying interface configuration information, user operation options, and test status, reading and writing files in the storage unit and generating application execution files, automatically generating test instructions according to the hardware interface to be tested and the set test parameters selected by the user, and determining the test results;

[0015] The product under test is used to complete the reception of the application execution file issued by the test device by running the boot program, and solidify it into the application program area of ​​the microprocessor, so as to complete the configuration of the corresponding hardware interface by updating the application program of the corresponding hardware interface; and is used to identify the test instructions, control the corresponding hardware interface according to the test instructions, and feedback the execution status information to the test device.

[0016] Furthermore, the product under test downloads a basic program adapted to the microprocessor it uses, including a boot program and initial applications for each hardware interface. When the hardware interface is configured, the boot program is started to write the application execution file of the configured interface into the application area of ​​the microprocessor, and the initial application of the corresponding hardware interface is upgraded. During the normal operation of the microprocessor, the application in the application area runs and communicates with the test device in real time to complete the test of the configured hardware interface.

[0017] Furthermore, the test device supports a variety of communication-to-serial port protocols, identifies the hardware interface of the product under test through the serial port, and establishes a two-way communication connection with the product under test according to a preset data format.

[0018] Furthermore, the test device integrates all interfaces covered by the microprocessor model used by the tested product, supports users to define interface properties as multiple types, including but not limited to: SPI, IO, PWM, SCI, IIC interfaces, etc.; and integrates the compilation system required by the software of the microprocessor model used by the tested product, which can call the compilation and generate application execution files through logic control instructions.

[0019] Furthermore, the logic processing control unit automatically generates a test instruction according to the hardware interface to be tested and the test parameters set by the user, including:

[0020] The logic processing control unit automatically associates a group of interfaces related to the attribute functions of the hardware interface to be tested selected by the user, and automatically presets the test execution content according to the interface attributes, and generates test instructions in combination with the user's setting of the hardware interface test parameters.

[0021] On the other hand, the present invention also provides an embedded product hardware testing method based on interface configuration, comprising:

[0022] S1. Establish two-way communication between the test device and the product under test;

[0023] S2. The user selects the hardware interface of the product under test on the test device for configuration;

[0024] S3, the test device automatically updates the initial application source code of the corresponding hardware interface stored locally according to the user configuration content, and calls the integrated development compilation environment to generate the application execution file;

[0025] S4, the test device sends the application execution file to the product under test;

[0026] S5. The product under test receives the application execution file by running the boot program and fixes it to the application program area of ​​the microprocessor, thereby completing the configuration of the corresponding hardware interface by updating the application program of the corresponding hardware interface;

[0027] S6. The user selects the successfully configured hardware interface of the product under test on the test device and sets the test parameters;

[0028] S7, the test device automatically generates a test instruction based on the successfully configured hardware interface and the set test parameters selected by the user and sends it to the product under test;

[0029] S8, the product under test controls the corresponding hardware interface according to the test instruction, and feeds back the execution status information to the test device;

[0030] S9. The testing device records and analyzes the data fed back by the tested product to generate the test results.

[0031] Further, in step S2, the user selects the hardware interface of the product under test on the test device for configuration, including:

[0032] The test device displays all hardware interfaces based on the microprocessor model of the tested product and the properties, attributes and characteristic parameter options of the hardware interfaces through a screen interface for the user to select and set.

[0033] Furthermore, step S5 also includes: if the configuration of the corresponding hardware interface is unsuccessful, re-running the application program before the configuration by powering on and resetting the product under test.

[0034] Furthermore, in step S7, the test device automatically generates a test instruction according to the successfully configured hardware interface and the set test parameters selected by the user, including:

[0035] The test device automatically associates a group of interfaces related to the attribute functions of the hardware interface to be tested selected by the user, and automatically presets the test execution content according to the interface attributes, and generates test instructions in combination with the user's setting of the hardware interface test parameters.

[0036] Further, in step S9, generating the test result includes:

[0037] If the hardware interface under test is an interface that can be tested independently, the test result is directly determined based on the test data fed back by the product under test; otherwise, the user is prompted to confirm the test result based on the actual measured data of the hardware interface.

[0038] The beneficial effects of the present invention are:

[0039] (1) Based on the solution of the present invention, hardware designers can independently complete interface configuration and testing, effectively avoiding anomalies that may be caused by the intervention of software designers, expanding the scope of troubleshooting of package failure phenomena, and failing to expose hardware problems caused by software code or logic errors. At the same time, there is no need for software personnel to cooperate, which reduces personnel investment in the hardware board-level testing stage and effectively improves labor efficiency.

[0040] (2) This solution provides user interface display and operation guidance, and can provide all interfaces based on the microprocessor model of the product under test for the operator to choose, including interface properties, characteristic parameters, and related parameters for setting, and can automatically generate test instructions that are consistent with the interface based on the interface configuration information, making this test workflow simple, intuitive, and convenient.

[0041] (3) This solution is commonly used in the development process of embedded products. It is applied in the hardware board-level testing phase of embedded products and can accurately and efficiently complete the testing and verification of the hardware status itself. For complex power supply systems involving external control interfaces, it can more effectively avoid system security issues caused by incorrect hardware-level test results. In addition, this solution supports a variety of communication to serial port methods, making this solution very widely used. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 It is a structural diagram of the embedded product hardware testing system based on interface configuration in the present invention;

[0043] Figure 2 It is a flow chart of the embedded product hardware testing method based on interface configuration in the present invention;

[0044] Figure 3 This is a schematic diagram of the test process in Example 1 of the present invention;

[0045] Figure 4 This is a schematic diagram of the test process in Example 2 of the present invention. DETAILED DESCRIPTION

[0046] The present invention aims to provide an embedded product hardware testing system and method based on interface configuration, which does not require software personnel to cooperate with hardware testing to make temporary software modifications, thereby eliminating exceptions caused by software logic and processing errors, ensuring the correctness and reliability of test results, and improving test efficiency. The core idea is: the test device provides hardware interface configuration options that match the microprocessor model of the tested product, and the user can independently configure the hardware interface. The test device automatically generates an application execution file according to the configuration content and sends it to the tested product. The tested product receives the file by running a boot program and solidifies it into the application area of ​​the microprocessor, thereby completing the configuration of the corresponding hardware interface by updating the application of the corresponding hardware interface. The user can set test parameters for the successfully configured hardware interface on the test device, and the test device automatically generates corresponding test instructions and sends them to the tested product to perform the test of the hardware interface. This solution does not require software personnel to cooperate with hardware testing to make temporary software modifications, and avoids manually writing code to implement logic control to complete hardware testing during the test process. It not only eliminates exceptions caused by software logic and processing errors, ensures the correctness and reliability of test results, but also improves the work efficiency of this test link.

[0047] In specific implementation, the embedded product hardware testing system based on interface configuration provided by the present invention is shown in Figure 1 , which includes a product under test and a testing device, wherein the product under test and the testing device are connected via a communication line.

[0048] Among them, for the embedded products of the power supply system, the product under test is a management control module, which in this solution completes the reception of the application execution file issued by the test device by running the boot program, and solidifies it into the application program area of ​​the microprocessor, thereby completing the configuration of the corresponding hardware interface by updating the application program of the corresponding hardware interface; and is used to identify the test instructions, control the corresponding hardware interface according to the test instructions, and feedback the execution status information to the test device.

[0049] The test device is a test device with interface display and operation functions, and has functions such as storage, display, human-computer interaction, communication, and logic processing. In this solution, it mainly provides an operation and display interface for users to configure the hardware interface of the product under test, automatically updates the initial application source code of the corresponding hardware interface stored locally according to the configuration content, and calls the integrated development compilation environment to generate the application executable file and send it to the product under test. In addition, it allows users to choose to set test parameters for the successfully configured hardware interface, and automatically generates test instructions and sends them to the product under test. In addition, it receives test feedback from the product under test, analyzes and records the test data, etc.

[0050] The test device includes a display and operation unit, an interface configuration unit, a communication unit, a storage unit, and a logic processing control unit. Specifically, the functions of each unit are described as follows:

[0051] The display and operation unit is used to display relevant information of the interface configuration, including the configuration interface type and interface-related parameter characteristics for users to view and select; provide real-time information prompts and display the configuration status and configuration results during the user's interface configuration of the product under test; and display the test status of the product under test.

[0052] The interface configuration unit is used to update the stored initial application source code of the corresponding hardware interface of the tested product according to the configuration operation of the user on the display and operation unit, and call the integrated development compilation environment to generate the application execution file.

[0053] The communication unit is used for two-way data communication between the test device and the product under test; it supports various communication to serial port protocols, including but not limited to: RS485, RS422, USB, etc.

[0054] The storage unit is used to store the initial application source code of each hardware interface of the tested product and the historical information of user operations.

[0055] The logic processing control unit is used to perform logic processing according to user operations and complete task scheduling of other functional units in the test device, including: displaying interface configuration information, user operation options, and test status, reading and writing files in the storage unit and generating application execution files, automatically generating test instructions based on the hardware interface to be tested and the set test parameters selected by the user, and determining the test results.

[0056] The test device in the present invention supports the following functions:

[0057] (1) Supports multiple communication to serial port protocols, identifies hardware through the serial port, and establishes a two-way communication connection with the product under test according to the preset data format to achieve data transmission.

[0058] (2) Integrate all interfaces covered by the microprocessor model used by the product under test, and support users to define interface properties into multiple types, including but not limited to: SPI, IO, PWM, SCI, IIC, etc.

[0059] (3) Integrate the compilation system required by the software of the microprocessor model used by the device under test, and be able to call the compilation and generate the executable file of the application through logical control instructions.

[0060] (4) Support file read and write operations. After the user saves the settings, the application software source file in the specified path can be read and written to update the software logic such as definition, initialization, drive, test control, etc. related to the interface set by the user to the corresponding program source file.

[0061] (5) Support data storage, store test history and related data information, and users can view the test history by operating the test device.

[0062] (6) Possess data analysis capabilities, analyze and process relevant information of user interface operations and data information received through communication in real time, and identify the current system status.

[0063] (7) It has the ability to process logic and perform logic processing according to the current system status to schedule related tasks of each functional unit, including but not limited to: displaying unit content and user operation options, configuring unit to read and write files and generate control instructions to mobilize program execution files, and testing unit to set test content for each interface and determine test results.

[0064] Based on the above system, the embedded product hardware testing method based on interface configuration provided by the present invention can be found in Figure 2 , which comprises the following steps:

[0065] S1. Establish two-way communication between the test device and the product under test;

[0066] In this step, the product under test needs to download the boot program and the initial application program in advance to ensure that the software runs normally after power-on and can establish normal communication with the test device. In terms of specific connection, a physical connection between the test device and the product under test can be established through a serial communication line. After normal power-on and operation, two-way data interaction between the two can be achieved through a preset mutually recognized and understood data format. The communication protocol supports various communication to serial port protocols, including but not limited to: RS485, RS422, USB, etc.

[0067] S2. The user selects the hardware interface of the product under test on the test device for configuration;

[0068] In this step, the test device displays all hardware interfaces based on the microprocessor model of the product under test and the properties, attributes and characteristic parameter options of the hardware interfaces through the screen interface for the user to select and set; based on this, the user can independently complete the configuration of the hardware interface of the product under test on the test device.

[0069] S3, the test device generates an application execution file according to the configuration content;

[0070] In this step, the test device automatically updates the initial application source code of the corresponding hardware interface stored locally according to the user configuration content, and calls the integrated development compilation environment to generate the application execution file.

[0071] S4, the test device sends the application execution file to the product under test;

[0072] In this step, the testing device sends the aforementioned generated application execution file to the product under test based on the communication between the testing device and the product under test.

[0073] S5. The product under test configures the corresponding hardware interface;

[0074] In this step, the product under test receives the application execution file by running the boot program and solidifies it into the application program area of ​​the microprocessor, thereby completing the configuration of the corresponding hardware interface by updating the application program of the corresponding hardware interface, and then jumping to execute the updated application program to initialize the successfully configured interface, so that it supports test control of the corresponding interface during the interface testing process.

[0075] S6. The user sets test parameters for the successfully configured hardware interface;

[0076] In this step, the user selects a successfully configured hardware interface of the product under test on the test device and sets the test parameters.

[0077] S7, the test device automatically generates test instructions and sends them to the tested product;

[0078] In this step, the test device automatically associates a group of interfaces related to the attribute functions of the hardware interface to be tested selected by the user, and automatically presets the test execution content according to the interface attributes, combines the user's setting of the hardware interface test parameters, generates test instructions, and then sends them to the product under test.

[0079] S8. The tested product performs the test and provides feedback;

[0080] In this step, the product under test controls the corresponding hardware interface according to the test instructions and feeds back the execution status information to the test device.

[0081] S9, the test device records data and generates test results;

[0082] In this step, the data fed back by the tested product is recorded and analyzed to generate test results. Among them, for interfaces involving output level and waveform control, the test results are confirmed by the user after the hardware is actually tested to see if they are consistent with the results of the test execution items, and the user gives the judgment result of whether the test passes or fails. The user can add notes as needed; for a class of interfaces that can be tested independently, the test results are unique or fixed, and do not require user confirmation. After the test is executed, the test results will be automatically determined based on the test data received by communication.

[0083] Example 1

[0084] In this embodiment, the device under test is a management control module in a power system, whose model is BMSMK-T01 (hereinafter referred to as the management control module), the DSP model used is JVP32F28335CQPM, and the communication method is RS422. In this embodiment, the external control circuit function test of this module outputting high and low level signals through the GPIO port is completed.

[0085] First, the management control module is powered on normally, the DSP runs the downloaded initial application normally, and the communication function is normal. The test device (hereinafter referred to as PZCS001) has been set up and stored with the software source code of the initial application. The device ID of this management control module is: 2024001001, and this is the first hardware interface test. Figure 3 Describe the specific steps for configuration and test execution for this example:

[0086] (1) Establish system connection:

[0087] Complete the physical connection between BMSMK-T01 and PZCS001 through the serial communication line, provide the required working power to BMSMK-T01, start and run the application program normally, and test the normal operation of the device.

[0088] (2) Test device starts connection:

[0089] BMSMK-T01 keeps communication receiving ready, and PZCS001 starts the connection process as follows:

[0090] (2.1) Identify new serial hardware: PZCS001 identifies new hardware through the COM port and prepares to establish a connection using serial data communication;

[0091] (2.2) Data communication connection: PZCS001 sends a command to start communication with BMSMK-T01 and obtain basic information of BMSMK-T01;

[0092] (2.3) Information display: After data processing, PZCS001 displays information on the interface, including: device name: BMSMK-T01, device ID: 2024001001, DSP model: JVP32F28335CQPMF, communication mode: RS422, test history: none.

[0093] After completing (1) and (2) above, see Figure 3 In Step 1 to Step 2, the test system is in normal working condition and has established a connection with the module under test. The user completes the configuration and testing of related interfaces in the interface according to the requirements of the test items.

[0094] Among them, the configuration function and execution process are shown in Figure 3 Step 3 to Step 6 mainly include:

[0095] (3) Set interface information:

[0096] This example completes the setting of I / O interface: GPIO23~GPIO26 are all common IO ports, definition: output, this example uses GPIO23 for explanation:

[0097] (3.1) Select hardware interface: GPIO23;

[0098] (3.2) Set the interface properties: Interface type: ordinary IO, Interface definition: output port;

[0099] (3.3) Save settings: store the data and status of the information set this time, and support modification or deletion operations after saving;

[0100] (3.4) Repeat the above steps (3.1 to 3.3) to complete the setting and saving of GPIO24 to GPIO26 respectively;

[0101] (3.5) After the interface information to be set is saved, wait for the user's operation to issue the execution configuration command to complete the configuration operation.

[0102] (4) Configuration process:

[0103] After the user interface sends the configuration instruction, the configuration process begins. PZCS001 completes the conversion of configuration information, generates the application execution file, and sends the configuration instruction and file content. BMSMK-T01 receives the configuration instruction and completes the reception and update of the application execution file. To ensure the integrity and correctness of the received file information content, the entire file transmission process is strictly executed in accordance with the pre-agreed process and data format. The main steps include:

[0104] (4.1) PZCS001 updates the software source file and calls compilation according to the saved interface setting information to generate the program execution file;

[0105] (4.2) PZCS001 sends a communication instruction to notify BMSMK-T01 to enter the configuration process and receive the program execution file;

[0106] (4.3) BMSMK-T01 recognizes the configuration instruction, jumps from the application to run the boot program, and starts receiving the program execution file;

[0107] (4.4) PZCS001 and BMSMK-T01 execute the transmission of file contents through a pre-agreed, mutually recognizable data format;

[0108] (4.5) BMSMK-T01 successfully receives the file data, updates the application area, and feeds back the result information of PZCS001 configuration completion, and automatically jumps to run the new application. If the received data is incomplete due to other abnormal reasons, the program area update fails, etc., it will feed back the result information of configuration failure and run the original application before configuration.

[0109] Test functions and execution process see Figure 3 Step 7 to Step 9 in the main process include:

[0110] (5) Testing process:

[0111] For the successfully configured interface, the test process is started by the user interface operation. PZCS001 is responsible for issuing the relevant test item instructions. BMSMK-T01 completes the control of the corresponding hardware interface and obtains information according to the received instructions. The main steps include:

[0112] (5.1) On the test page, the user can view the configured hardware interface information. The user selects the interface GPIO23 to be tested, sets the parameter: 0 (low level), and operates the start test command;

[0113] (5.2) PZCS001 generates the control instruction for testing the interface GPIO23 selected by the user: CSIO-GPIO23-SC-0, and sends it to BMSMK-T01 through communication. If the user sets the parameter: 1 (high level) in (5.1), the generated test instruction is: CSIO-GPIO23-SC-1;

[0114] (5.3) BMSMK-T01 receives this instruction, executes the control of the DSP's GPIO23 port outputting a low level, and feeds back the result of the status "operation completed";

[0115] (5.4) When PZCS001 receives the feedback result of "Operation Completed", it prompts the user to actually measure whether the output level of the hardware IO port GPIO23 of BMSMK-T01 or its related circuit is low, and confirm the result of this test (low: test passed, otherwise the test failed), and can add remarks as needed;

[0116] (5.5) After the user confirms the result, PZCS001 will save the test data and results, and the user can view them in the test history. Repeat (5.1 to 5.5) to complete other common IO port output control functions that need to be tested.

[0117] (6) Test completed:

[0118] For the tested interface, the user will display the test history data and results after selecting it again, but it will not affect the user's re-testing (the above (5)) operation. The user can view it in the test history. The interface supports the list format to display the information of the tested interface, and can also export the table as the test data for the preparation of the test report. The test result information after completing the configuration and testing of this example includes:

[0119] Hardware IO interface: GPIO23, interface attribute: output, test status: completed, test data: 0 / 1, execution time: 2024030111:25:56, test result: passed, remarks: none;

[0120] Hardware IO interface: GPIO24, interface attribute: output, test status: completed, test data: 0 / 1, execution time: 2024030111:26:10 test result: passed, remarks: none;

[0121] Hardware IO interface: GPIO25, interface attribute: output, test status: completed, test data: 0 / 1, execution time: 2024030111:26:46 test result: failed, remarks: output low level is invalid;

[0122] Hardware IO interface: GPIO26, interface attributes: output, test status: completed, test data: 0 / 1, execution time: 2024030111:26:59 test result: passed, remarks: none.

[0123] The above-mentioned embodiment 1 is aimed at testing the high and low levels of the output of the GPIO port defined as an ordinary IO by the DSP. When the hardware design defines the high and low level output characteristics of the GPIO port as a non-ordinary IO, the test device will identify it according to the interface attributes configured by the user, prompt the user to enter the relevant parameters involved in the interface attributes, and generate a test instruction matching it according to the attributes configured by the user. During the test, the relevant control operations on this interface are completed. Based on embodiment 1, the functional test of the GPIO port outputting a PWM waveform is described below, assuming that the hardware design controls the output PWM wave of the GPIO26 interface.

[0124] (1) Based on item (3) of Example 1, set the interface information:

[0125] (1.1) Select hardware interface: GPIO26;

[0126] (1.2) Set interface properties: Interface type: PWM, Interface definition: Output;

[0127] (1.3) Interface attribute related parameter settings: PWM output frequency: 25KHz, duty cycle: 50%;

[0128] (1.4) Save settings: store the PWM output waveform parameter definition set this time;

[0129] (1.5) The user sends and executes the configuration command to complete the configuration of the PWM output of the GPIO26 interface.

[0130] (2) Complete the configuration according to the process (4) of Example 1. The user operates the test of the PWM wave output of the configured GPIO26 port:

[0131] (2.1) The user selects the interface GPIO26 to be tested on the test page and issues a test command;

[0132] (2.2) PZCS001 generates the operation instruction for testing this interface based on the configuration information of the current interface GPIO26 selected: CSIO-GPIO26-PWM-1-25-50, and sends it to BMSMK-T01 through communication;

[0133] (2.3) BMSMK-T01 receives this test instruction, executes the GPIO26 interface to control the output of PWM wave, the waveform frequency is 25KHz, the duty cycle is 50%, and feedbacks the result of "operation completed";

[0134] (2.4) After receiving the feedback of "Operation Completed", PZCS001 prompts the user to confirm whether the output of the GPIO26 port of BMSMK-T01 or its related circuit is a waveform of 25KHz and 50% duty cycle, and confirm the test result of this item;

[0135] (3) After the test is completed, the result information for this test is as follows:

[0136] Hardware IO interface: GPIO26, Interface properties: PWM, Test status: Completed, Test data: PWM waveform, Execution time: 2024030114:10:50 Test result: Passed, Remarks: 25KHz, 50%.

[0137] During the configuration process, the user can set different PWM parameters and test the waveforms with different properties of the control interface output. For example, before configuration, the interface attribute related parameters are set to PWM output frequency: 50KHz, duty cycle: 75%. The operation instruction for testing this interface is: CSIO-GPIO26-PWM-1-50-75. When executing the test, the management control module will control the interface to output PWM waves according to the set parameters.

[0138] Example 2

[0139] In this embodiment, the management control module (BMSMK-J01) uses the same model of main chip as Example 1, and the communication mode is RS485, which is applied to different system product models. This example mainly describes how DSP realizes data read and write control with the external storage unit through SPI communication, and completes the test of the external storage function of BMSMK-J01.

[0140] The device ID of BMSMK-J01 is: 2024002005. Some hardware interface configuration and testing have been completed. After power-on, the DSP will run the application program updated in the last configuration, and the communication is normal. The application software source code stored in the corresponding path of the test device PZCS001 used in Example 1 is updated in the last configuration operation. Figure 4 Describe the specific steps to test whether the external storage function module is normal through this solution:

[0141] (1) PZCS001 operates normally. The physical connection between PZCS001 and BMSMK-J01 is established through the RS485 to serial communication line. BMSMK-J01 enters normal operation after the power supply is turned on.

[0142] (2) PZCS001 recognizes the hardware BMSMK-J01 and establishes a data communication connection with it. According to the feedback information from BMSMK-J01, it automatically associates its original test history information. After data processing, the basic information displayed is: device name: BMSMK-J01, device ID: 2024002005, processor model: JVP32F28335CQPM, communication mode: RS485, test history: yes. Users can view the existing test records.

[0143] (3) Set interface information:

[0144] Set a group of interfaces related to the SPI communication function as follows: GPIO24 is SIMO, GPIO26 is SOMI, GPIO25 is the clock signal, and GPIO20 is the CS chip select signal. The operation is as follows:

[0145] (3.1) Select hardware interface: GPIO24;

[0146] (3.2) Set interface properties: Interface type: SPI communication, Interface definition: input / output;

[0147] (3.3) Set SPI related interfaces: Select: GPIO24, define: SPI-SIMO; Select: GPIO26, define: SPI-SOMI; Select interface: GPIO25, define: SPI-CLK; Select interface: GPIO20, define: SPI-CS;

[0148] (3.3) Save settings: save a set of interface definition information associated with the SPI settings;

[0149] (3.4) The user operates and issues execution configuration instructions to complete the configuration of this group of SPI communication related interfaces.

[0150] (4) After completing the configuration according to the process (4) of Example 1, the user starts the test process. PZCS001 is responsible for issuing the test instructions, and BMSMK-J01 performs the corresponding interface control operations according to the received instructions. The main steps are as follows:

[0151] (4.1) On the test page, the user selects the interface GPIO24 (or GPIO25, GPIO26, GPIO20) to be tested, and the system will automatically associate the group of related interfaces. The user sets the data area content: 0xAB 0xCD0x120x34, and operates the start test command;

[0152] (4.2) PZCS001 generates the operation instruction for testing this group of interfaces according to the configuration information of the group of test interfaces selected by the user: CSIOS-SPI-WR-0, and sends it to BMSMK-J01 through communication;

[0153] (4.3) BMSMK-J01 receives this instruction and executes the write and read operations of data (0xAB0xCD 0x120x34) to the external memory through SPI communication. The result of this test instruction is unique and the user does not need to confirm the test result. The test will feedback the test status "in progress" or "completed", as well as the result of pass or fail.

[0154] (4.4) PZCS001 will receive the feedback status and result information, save the test data and results, and the user can view them in the test history.

[0155] (5) After the test is completed, the result information for this test is as follows:

[0156] Hardware IO interface: GPIO24, interface attributes: SPI-SIMO, test status: completed, test data: 0xAB0xCD 0x120x34, execution time: 2024040114:10:50 test result: passed, remarks: none.

[0157] Hardware IO interface: GPIO25, interface attributes: SPI-CLK, test status: completed, test data: 0xAB 0xCD0x120x34, execution time: 2024040114:10:50 test result: passed, remarks: none.

[0158] Hardware IO interface: GPIO26, interface attributes: SPI-SOMI, test status: completed, test data: 0xAB0xCD 0x120x34, execution time: 2024040114:10:50 test result: passed, remarks: none.

[0159] Hardware IO interface: GPIO20, interface attributes: SPI-CS, test status: completed, test data: 0xAB 0xCD0x120x34, execution time: 2024040114:10:50 test result: passed, remarks: none.

[0160] Based on Example 2, when DSP involves multiple circuit function units sharing the SPI communication interface, the hardware design uses different interfaces to control the validity of the SPI chip select signal, and realizes the information interaction between the SPI data read and write interface and different circuit function units. This method provides an extended control interface test for grouped interfaces. When configuring and setting the SPI interface, the user can add settings by operation, add settings for the extended GPIO port, and complete the configuration of multiple chip select interfaces based on SPI communication. Now we will further explain the addition of settings to facilitate the understanding of the execution process of this solution.

[0161] By adding settings, the user configures the second chip select signal interface of SPI. When executing the test, the chip select signal interface is controlled to enable BMSMK-J01 to obtain the voltage data returned by the battery voltage acquisition circuit unit through SPI communication. The above Example 2 has completed the test of the DSP's read and write control function of the external memory through SPI communication by controlling the GPIO20 signal to be valid. This operation is: the user enters the configuration page again and queries the SPI interface setting information that has been configured in Example 2. The user operates "Modify settings", and the setting status of this group of interfaces is turned into an editable state. The existing setting information of Example 2 is not modified. Select "Add settings". This example sets: GPIO18, defined as: SPI-CS. The user saves the settings and sends the configuration instructions to complete the configuration of the newly added interface. After the configuration is completed, the latest definition of this group of SPI-related interfaces is:

[0162] Interface: GPIO24, definition: SPI-SIMO;

[0163] Interface: GPIO26, definition: SPI-SOMI;

[0164] Interface: GPIO25, definition: SPI-CLK,

[0165] Interface: GPIO20, definition: SPI-CS;

[0166] Interface: GPIO18, definition: SPI-CS.

[0167] Enter the test page, the user selects the test interface GPIO24 (or GPIO26, GPIO25, GPIO20, GPIO18), the system will automatically associate this group of SPI related interfaces. For the test process of this example, see Figure 4 The hint:

[0168] (1) GPIO20 and GPIO18 are defined as the same type. The system prompts the user to complete the setting of the interface control status. GPIO20 is set to 0 and GPIO18 is set to 1. This test is a data acquisition test. There is no need to set the data area content. Directly operate the start test command;

[0169] (2) PZCS001 generates the execution instruction for testing this group of interfaces based on the configuration information of the group of interfaces selected by the user: CSIOS-SPI-WR-1, and sends it to BMSMK-J01 through communication;

[0170] (3) BMSMK-J01 receives this instruction, controls GPIO18 port to output a high level signal (valid), controls GPIO20 port to output a low level signal (invalid), executes the SPI communication test to read the battery voltage data, and feeds back the execution status: "Operation completed" and the read data information, prompting the user to confirm whether the value obtained by BMSMK-J01 through SPI voltage acquisition is consistent with the actual measured value of the input end of the hardware-related circuit (including the limitation of the performance error range), and confirms the test result of this article, and can supplement the remarks information as needed;

[0171] (4) After executing this test in this example, the value returned by the receiving test is: 3540 (0x0DD4), that is, the battery voltage value obtained by the software SPI interface is 3540mV, which is in line with the deviation from the actual value input by the hardware circuit unit (3543mV). After the test is completed, the result information for this test is as follows:

[0172] Hardware IO interface: GPIO24, interface attributes: SPI-SIMO, test status: completed, test data: 0x0D0xD4, execution time: 2024040214:10:50 test result: passed, remarks: none.

[0173] Hardware IO interface: GPIO25, interface attributes: SPI-CLK, test status: completed, test data: 0x0D0xD4, execution time: 2024040214:10:50 test result: passed, remarks: none.

[0174] Hardware IO interface: GPIO26, interface attributes: SPI-SOMI, test status: completed, test data: 0x0D0xD4, execution time: 2024040214:10:50 test result: passed, remarks: none.

[0175] Hardware IO interface: GPIO20, interface attributes: SPI-CS, test status: completed, test data: 0x0D 0xD4, execution time: 2024040214:10:50 test result: passed, remarks: none.

[0176] Hardware IO interface: GPIO18, interface attributes: SPI-CS, test status: completed, test data: 0x0D 0xD4, execution time: 2024040214:10:50 test result: passed, remarks: voltage sampling value, error -3mV.

[0177] For the above examples 1 and 2, when there are exceptions, user operation errors, data loss, and other abnormal execution and response instructions during the configuration or test process, the operation interface will give corresponding prompt information and guide the user to perform corresponding operations. If the configuration is unsuccessful due to communication abnormalities, system power failure, etc., after powering on again, the management control module can enter the normal working state and run the application before configuration. The user can complete the relevant tests after reconfiguration.

[0178] Based on the records of the embodiments of the present invention, the solution provided by the present invention does not require software personnel to cooperate with hardware testing to make temporary software modifications, and avoids manual code writing to implement logic control to complete hardware testing during the testing process. It not only eliminates anomalies caused by software logic and processing errors, ensures the correctness and reliability of the test results, but also improves the work efficiency of this testing link.

[0179] Finally, it should be noted that the above embodiments are only preferred implementations and are not intended to limit the present invention. It should be pointed out that for those skilled in the art, several modifications, equivalent replacements, improvements, etc. can be made without departing from the scope of the present invention and the scope of protection of the claims, and all of these should be included in the protection scope of the present invention.

Claims

1. An embedded product hardware testing system based on interface configuration, comprising a product under test and a testing device; the product under test and the testing device are connected via a communication line; characterized in that, The test device includes a display and operation unit, an interface configuration unit, a communication unit, a storage unit and a logic processing control unit; The display and operation unit is used to display relevant information of the interface configuration, including the configuration interface type and interface-related parameter characteristics for the user to view and select; During the user's interface configuration process of the product under test, real-time information prompts, configuration status, and configuration results are displayed; as well as the display and operation for setting test parameters and displaying the test status of the product under test; The interface configuration unit is used to update the stored initial application source code of the corresponding hardware interface of the tested product according to the configuration operation of the user on the display and operation unit, and call the integrated development compilation environment to generate the application execution file; The communication unit is used for two-way data communication between the test device and the product under test; The storage unit is used to store the initial application source code of each hardware interface of the tested product and the historical information of user operations; The logic processing control unit is used to perform logic processing according to user operations and complete task scheduling of other functional units in the test device, including: displaying interface configuration information, user operation options, and test status, reading and writing files in the storage unit and generating application execution files, automatically generating test instructions according to the hardware interface to be tested and the set test parameters selected by the user, and determining the test results; The product under test is used to complete the reception of the application execution file issued by the test device by running the boot program, and solidify it into the application program area of ​​the microprocessor, so as to complete the configuration of the corresponding hardware interface by updating the application program of the corresponding hardware interface; and is used to identify the test instructions, control the corresponding hardware interface according to the test instructions, and feedback the execution status information to the test device.

2. An embedded product hardware testing system based on interface configuration as claimed in claim 1, characterized in that: The tested product downloads a basic program adapted to the microprocessor used by it, including a boot program and initial application programs of each hardware interface. When the hardware interface is configured, the boot program is started and run, and the application execution file of the configured interface is written into the application program area of ​​the microprocessor, and the initial application program of the corresponding hardware interface is upgraded and updated; The microprocessor runs the application program in the application program area during normal operation, communicates with the test device in real time, and completes the test of the configured hardware interface.

3. An embedded product hardware testing system based on interface configuration as claimed in claim 1, characterized in that: The test device supports multiple communication-to-serial port protocols, identifies the hardware interface of the product under test through the serial port, and establishes a two-way communication connection with the product under test according to a preset data format.

4. The embedded product hardware testing system based on interface configuration as claimed in claim 1, characterized in that: The test device integrates all interfaces covered by the microprocessor model used by the tested product, supports users to define interface properties as multiple types, including SPI, IO, PWM, SCI, and IIC interfaces; and integrates the compilation system required by the software of the microprocessor model used by the tested product, which can call the compilation and generate application execution files through logic control instructions.

5. An embedded product hardware testing system based on interface configuration as described in any one of claims 1 to 4, characterized in that: The logic processing control unit automatically generates a test instruction according to the hardware interface to be tested and the test parameters set by the user, including: The logic processing control unit automatically associates a group of interfaces related to the attribute functions of the hardware interface to be tested selected by the user, and automatically presets the test execution content according to the interface attributes, and generates test instructions in combination with the user's setting of the hardware interface test parameters.

6. A method for testing embedded product hardware based on interface configuration, characterized in that: include: S1. Establish two-way communication between the test device and the product under test; S2. The user selects the hardware interface of the product under test on the test device for configuration; S3, the test device automatically updates the initial application source code of the corresponding hardware interface stored locally according to the user configuration content, and calls the integrated development compilation environment to generate the application execution file; S4, the test device sends the application execution file to the product under test; S5. The product under test receives the application execution file by running the boot program and fixes it to the application program area of ​​the microprocessor, thereby completing the configuration of the corresponding hardware interface by updating the application program of the corresponding hardware interface; S6. The user selects the successfully configured hardware interface of the product under test on the test device and sets the test parameters; S7, the test device automatically generates a test instruction based on the successfully configured hardware interface and the set test parameters selected by the user and sends it to the product under test; S8, the product under test controls the corresponding hardware interface according to the test instruction, and feeds back the execution status information to the test device; S9. The testing device records and analyzes the data fed back by the tested product to generate the test results.

7. The embedded product hardware testing method based on interface configuration as claimed in claim 6, characterized in that: In step S2, the user selects the hardware interface of the product under test on the test device for configuration, including: The test device displays all hardware interfaces based on the microprocessor model of the tested product and the properties, attributes and characteristic parameter options of the hardware interfaces through a screen interface for the user to select and set.

8. The method for testing embedded product hardware based on interface configuration as claimed in claim 6, characterized in that: Step S5 also includes: if the configuration of the corresponding hardware interface is unsuccessful, re-running the application program before the configuration by powering on and resetting the product under test.

9. The method for testing embedded product hardware based on interface configuration as claimed in claim 6, characterized in that: In step S7, the test device automatically generates a test instruction according to the successfully configured hardware interface selected by the user and the set test parameters, including: The test device automatically associates a group of interfaces related to the attribute functions of the hardware interface to be tested selected by the user, and automatically presets the test execution content according to the interface attributes, and generates test instructions in combination with the user's setting of the hardware interface test parameters.

10. An embedded product hardware testing method based on interface configuration as claimed in any one of claims 6 to 9, characterized in that: In step S9, generating the test result includes: If the hardware interface under test is an interface that can be tested independently, the test result is directly determined based on the test data fed back by the product under test; otherwise, the user is prompted to confirm the test result based on the actual measured data of the hardware interface.

Images