Automatic testing system and method for single-chip microcomputer firmware library

Abstract

The invention relates to an automatic testing system and method for a single-chip microcomputer firmware library. The system comprises a software upper computer, a test bottom plate and a tested chip substrate which are in communication connection in sequence, the test bottom plate comprises a control chip and a switch matrix circuit, the tested chip substrate comprises a tested chip, and the switch matrix circuit gates line connection between the two chips. The system is configured as follows: a software upper computer generates a firmware library test program according to the model of a tested chip, and downloads the firmware library test program to a control chip and the tested chip; after the control chip controls the switch matrix circuit to gate corresponding line connection according to the test program, the tested chip runs the test program, and the control chip performs test driving and response acquisition on the tested chip; and the tested chip judges the test result according to the response acquired by the control chip, and uploads the test result to the software upper computer through the control chip. By means of the method, automatic execution, comprehensive coverage and result standardized management of the firmware library testing process can be achieved.

Description

Technical Field

[0001] This application relates to the field of microcontroller technology and its automated testing, and in particular to an automated testing system and method for microcontroller firmware libraries. Background Technology

[0002] In the field of microcontroller technology and its automated testing, functional verification and test management of microcontroller firmware libraries are crucial for improving the efficiency and quality of firmware library development. Current microcontroller firmware library testing methods involve manually setting up test environments and using methods such as LED indicators, serial port printing, or pin waveform observation to achieve functional verification. However, this method suffers from drawbacks such as high workload, low efficiency, insufficient test coverage, high repeatability and error-proneness, and high subjectivity in result judgment, making it difficult to conduct comprehensive and efficient testing of complex firmware libraries. Summary of the Invention

[0003] Therefore, it is necessary to provide an automated testing system and method for microcontroller firmware libraries to address the aforementioned technical problems and solve the difficulty in conducting comprehensive and efficient testing of complex firmware libraries.

[0004] In a first aspect, this application provides an automated testing system for a microcontroller firmware library, the system comprising a software host computer, a test baseboard, and a chip substrate under test that are sequentially and communicatively connected. The test baseboard includes a control chip and a switch matrix circuit. The chip under test substrate includes the chip under test. The switch matrix circuit is connected to the control chip and the chip under test respectively, and selects the circuit connection between the two. The system is configured as follows: The host computer generates a firmware library test program based on the model of the chip under test, and downloads it to the control chip and the chip under test. After the control chip controls the switch matrix circuit to select the corresponding line connection according to the firmware library test program, the chip under test runs the firmware library test program, and the control chip performs test driving and response acquisition on the chip under test. The chip under test determines the test results based on the response collected by the control chip, and uploads the test results to the software host computer through the control chip.

[0005] Secondly, this application also provides an automated testing method for a microcontroller firmware library, characterized in that the method is applied to an automated testing system for the microcontroller firmware library; The method includes: The host computer generates a firmware library test program based on the model of the chip under test, and downloads it to the control chip and the chip under test. After the control chip controls the switch matrix circuit to select the corresponding line connection according to the firmware library test program, the chip under test runs the firmware library test program, and the control chip performs test driving and response acquisition on the chip under test. The chip under test determines the test results based on the response collected by the control chip, and uploads the test results to the software host computer through the control chip.

[0006] The aforementioned automated testing system and method for microcontroller firmware libraries firstly involves a host computer selecting and loading a matching firmware library test program based on the model of the chip under test. This enables centralized management and unified scheduling of test cases, reducing manual configuration workload. Secondly, a control chip controls a switch matrix circuit to select the corresponding line connections and execute test drivers and response acquisition, thereby achieving automated execution of the testing process and multi-interface coverage, improving testing efficiency and expanding the testing coverage. Thirdly, the chip under test determines the test results based on the response data and uploads the results to the host computer via the control chip, achieving objective determination and centralized recording of test results, reducing human intervention and judgment errors. Based on this, the entire technical solution achieves automated execution, comprehensive coverage, and standardized management of the firmware library testing process, overcoming the problems of low efficiency, insufficient coverage, and strong subjectivity in manual testing. Attached Figure Description

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

[0008] Figure 1 This is a block diagram of an automated testing system for a microcontroller firmware library in one embodiment. Figure 2 This is a block diagram of an automated testing system for a microcontroller firmware library in another embodiment; Figure 3 This is a schematic diagram of the circuit connection and switching between the control chip and the chip under test in a test baseboard in one embodiment; Figure 4 This is a schematic diagram of the control chip pinouts and interface connections in one embodiment. Figure 5 This is a schematic diagram of the CAN bus communication interface circuit in one embodiment; Figure 6 This is a schematic diagram of the structure of an analog signal detection circuit in one embodiment; Figure 7This is a schematic diagram of the LIN bus communication interface circuit in one embodiment; Figure 8 This is a schematic diagram of the power processing circuit in one embodiment; Figure 9 This is a flowchart illustrating an automated testing method for a microcontroller firmware library in one embodiment. Detailed Implementation

[0009] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0010] In one exemplary embodiment, such as Figure 1 As shown, an automated testing system for a microcontroller firmware library is provided. The system includes a software host computer, a test baseboard, and a chip substrate under test that are sequentially and communicatively connected. The test baseboard includes a control chip and a switch matrix circuit, the chip substrate under test includes the chip under test, and the switch matrix circuit is connected to the control chip and the chip under test respectively, and selects the circuit connection between the two.

[0011] The system is configured as follows: The host computer generates a firmware library test program based on the model of the chip under test, and downloads it to the control chip and the chip under test. After the control chip controls the switch matrix circuit to select the corresponding line connection according to the firmware library test program, the chip under test runs the firmware library test program, and the control chip performs test driving and response acquisition on the chip under test. The chip under test determines the test results based on the response collected by the control chip, and uploads the test results to the host computer via the control chip.

[0012] For example, the host computer, acting as the master control device for managing the entire testing process, first obtains the model number of the chip under test (DUT), and then selects a firmware library test program matching the DUT from the configured firmware library test program set. The firmware library test program includes a BSP (Board Support Package) firmware library and a set of test cases generated by a testing framework (e.g., Unity). The host computer then configures the execution order of the internal test case set based on the selected firmware library test program, ensuring that the test case set has a clear calling order and execution relationship during subsequent execution. This guarantees that the control chip and the DUT can collaboratively process based on the same test logic. For example, the execution order is determined according to the dependencies between test cases, and test cases corresponding to the initialization process, function call process, and result determination process of the same functional interface are associated and organized. After selecting and configuring the firmware library test program, the host computer writes the firmware library test program to the control chip and the chip under test respectively through a predetermined download method (such as burning through the burning interface). This enables the control chip to execute the scheduling control corresponding to the test case set, and at the same time enables the chip under test to execute the functional verification corresponding to the test case set, thereby establishing a unified and consistent test execution basis.

[0013] For example, the test baseboard, serving as a hardware platform connecting the software host computer and the chip under test (DUT) substrate, receives the firmware library test program from the software host computer. The control chip within the baseboard controls the test process according to the execution order of the test case set, and dynamically selects the line connections between the control chip and the DUT through a switch matrix circuit. The switch matrix circuit establishes corresponding connections between specific pins of the control chip and specific pins of the DUT at different test stages, enabling each test case to execute under matched line connection conditions. It also switches between different pins and peripherals in a time-division manner, allowing a single control chip to cover all functional interfaces of the DUT during different test periods. After the corresponding line connections are established, the DUT executes test operations by calling the corresponding functional interfaces according to the firmware library test program. Simultaneously, the control chip, based on the requirements of the current test case, outputs the corresponding test stimulus signal to the DUT through the selected line and monitors and collects the output signals generated by the DUT during execution, thereby obtaining the response signal corresponding to the test case to characterize the actual output of the DUT during the execution of the corresponding functional interface.

[0014] For example, the chip under test (DUT) substrate serves as a hardware platform carrying DUTs of different models and packaging methods. After completing the execution of the current test case, the DUT currently mounted on the substrate judges the test results based on the response signals collected by the control chip. Specifically, the DUT compares the response signals with the expected results of the corresponding test case according to preset judgment conditions in the firmware library test program, thereby obtaining the test result corresponding to the current test case to characterize whether the corresponding functional interface meets the preset requirements. After generating the test results, the DUT transmits the test results to the control chip through a preset communication method (e.g., outputting the test results of each test case one by one via a serial port). The control chip receives and organizes the test results of each test case and summarizes them according to a preset data format (e.g., sequentially encoding and combining the test results according to the test case execution order) to form an overall test result corresponding to the test case set. The control chip then uploads the overall test result to the software host computer, which receives and records the result data, thus completing the collection and management of the entire test process results.

[0015] Optionally, the testing framework is configured as follows: test cases are provided with a unified writing standard; test cases are executed and test results are generated; the test results are verified for consistency using an assertion mechanism; and the test results are sent to the control chip and the software host computer via a preset communication channel. Specifically, the testing framework first provides a unified test case writing standard. For example, for BSP functions such as GPIO and UART, test cases for initialization, parameter configuration, and function calls are written in a unified format to ensure consistency in the testing methods for different functions. During the execution phase, the testing framework automatically calls each test case in a predetermined order. For example, it calls the UART transmit function and records its output data, or calls the GPIO control function and detects changes in pin levels, thereby generating corresponding test results. Based on this, the test results are verified for consistency using an assertion mechanism, such as determining whether the function return value meets expectations, whether the register configuration is correct, or whether the output data is consistent. After verification, the test results corresponding to each test case are sent to the control chip and the software host computer via a preset communication channel (such as a serial port) to achieve unified transmission and recording of test results.

[0016] Optionally, the peripherals that drive the test of the chip under test (DUT) include at least one of GPIO (General Purpose Input / Output), UART (Universal Asynchronous Receiver / Transmitter), SPI (Serial Peripheral Interface), ADC (Analog-to-Digital Converter), and timers. The test stimulus signals generated by these peripherals include at least one of high / low levels, PWM waves, serial data with a preset protocol, and analog voltages. Specifically, the same peripheral can generate different forms of test stimulus signals under different configurations or control methods. For example, GPIO is used to generate high / low level signals or pulse signals through periodic toggling; timers are used to generate PWM waves or level change signals with a specific period; UART and SPI are used to generate serial data with a preset protocol; and ADC is used to generate corresponding analog voltage signals. Based on this, each peripheral can generate different types of test stimulus signals according to test requirements to adapt to test scenarios of different functional interfaces.

[0017] Optionally, the switch matrix circuit is connected to the transmit pin of the chip under test (DUT) and the receive pin of the control chip, and is also connected to the receive pin of the DUT and the transmit pin of the control chip, respectively, and selects the line connections between the pins. Specifically, the line connection between the transmit pin of the DUT and the receive pin of the control chip is used to transmit the response signal output by the DUT when running the firmware library test program to the control chip for storage; the line connection between the receive pin of the DUT and the transmit pin of the control chip is used to send the test excitation signal output by the control chip to the DUT and send the response signal stored by the control chip to the DUT, so that the DUT can determine the test result based on the response signal.

[0018] Furthermore, in this technical solution, the system adopts a split architecture of a universal test baseboard and a replaceable chip-under-test substrate. That is, the system is divided into a general part with fixed functions and a variable adaptable part. The test baseboard, as a general platform, integrates control chips, switch matrix circuits and related test resources to realize test scheduling, signal driving and response acquisition. The chip-under-test substrate is used to carry chips of different models or packages and provides peripheral circuit support that matches the chips under test. By separating the two, the test baseboard does not need to be adjusted with changes in the chips under test. It can be adapted to different test objects simply by replacing the chip-under-test substrate, thereby realizing the universality and scalability of the system structure.

[0019] Furthermore, this technical solution involves automated testing of the driver function-level call process in the BSP firmware library and judgment of the test results. The test object is the software layer interface and its coordination relationship with the underlying hardware. In contrast, conventional MCU automatic test systems focus on electrical characteristic testing (such as FT testing) or application layer functional testing during the chip manufacturing stage, and lack a dedicated automated testing solution for BSP layer code, especially driver function level across chip models. Based on this, this technical solution differs from the above-mentioned conventional technologies in terms of test object and test level, and has an independent technical approach. Conventional technologies do not provide corresponding technical inspiration.

[0020] Therefore, the automated testing system for microcontroller firmware libraries proposed in this technical solution effectively improves testing efficiency, accuracy, and comprehensiveness, and enhances the standardization and traceability of the testing process. At the same time, the system has good adaptability and versatility, can support chip difference analysis, and thus assist R&D personnel in chip design optimization and MCU firmware library development, and provide more accurate technical support for applications, thereby improving the overall competitiveness of products.

[0021] Furthermore, the aforementioned switch matrix circuit centrally manages the circuit connections between the control chip and the chip under test through multiple switch paths, and covers multiple types of pin connection relationships under the same circuit structure. This allows for switching of circuit connections corresponding to different test cases without changing the hardware wiring, improving the flexibility of circuit usage compared to conventional fixed connection methods. Based on this, further grouping and controlling the circuit connections corresponding to different types of pins can enable or switch the same type of circuit connection as a whole, reducing the control overhead of switching each circuit individually. Simultaneously, multiple selectable circuit connections can be set for the same pin, switching to another circuit to re-establish the connection when one circuit malfunctions, thereby improving the stability and availability of the circuit connections.

[0022] Furthermore, the circuit connection status of the switch matrix circuit can be uniformly managed and represented by the control chip. Each selectable circuit connection between a control chip pin and a pin of the chip under test can be defined as a connection relationship, and a corresponding connection identifier can be assigned to each connection relationship. In the specific implementation, the control chip combines the required connection relationships according to the test cases to form a set of circuit connection states for the current test phase. This set of circuit connection states represents all currently selected circuit connections. By updating and switching this set of circuit connection states, orderly changes in circuit connection states between different test cases can be achieved. Simultaneously, each circuit connection state can be recorded, ensuring the configurability and traceability of circuit connection relationships corresponding to different test cases, thereby achieving unified management and representation of the circuit connection status of the switch matrix circuit.

[0023] In this embodiment, firstly, the host computer selects and loads the matching firmware library test program according to the model of the chip under test, thereby achieving centralized management and unified scheduling of test cases and reducing the workload of manual configuration. Secondly, the control chip controls the switch matrix circuit to select the corresponding line connection and execute test drive and response acquisition, thereby achieving automatic execution of the test process and multi-interface coverage, improving test efficiency and expanding the test coverage. Thirdly, the chip under test judges the test results based on the response data and uploads them to the host computer via the control chip, thereby achieving objective judgment and centralized recording of test results and reducing human intervention and judgment errors. Based on this, the entire technical solution realizes automated execution, comprehensive coverage and standardized management of the firmware library testing process, thereby overcoming the problems of low efficiency, insufficient coverage and strong subjectivity of manual testing.

[0024] In one exemplary embodiment, in Figure 1 Based on the structure of the automated testing system for the microcontroller firmware library shown, such as Figure 2 As shown, the test baseboard also includes a power supply circuit for the chip under test and a first auxiliary test circuit, and the chip under test substrate also includes a second auxiliary test circuit.

[0025] The test chip power supply circuit is connected to the test chip substrate to provide operating power to the test chip substrate; one end of the first auxiliary test circuit is connected to the control chip, and the other end is connected to the test chip or the second auxiliary test circuit via a switch matrix circuit to provide general test load and standardized peripheral function support; the second auxiliary test circuit is connected to the test chip to provide the peripheral circuit support required for the operation of the test chip.

[0026] For example, the power supply circuit of the chip under test is used to provide a stable operating power supply to the chip under test substrate. Its function is to provide a unified and controllable power supply condition for the chip under test and its peripheral circuits, thereby ensuring that the chip under test is always in normal working condition during the execution of each test case.

[0027] The first auxiliary test circuit is located on the test baseboard side and is used to provide general test loads and standardized peripheral function support, so that the control chip can simulate a variety of general peripheral environments during the test. For example, it can provide IIC (Inter-Integrated Circuit) pull-up conditions to meet bus communication requirements, provide CAN (Controller Area Network) or LIN (Local Interconnect Network) transceiver support to realize corresponding communication function tests, and provide multi-level filtering conditions to realize ADC (Analog-to-Digital Converter) related function tests, so that different types of functional tests can be completed in a unified test environment.

[0028] The second auxiliary test circuit is located on the substrate side of the chip under test. It is used to provide the chip under test with minimum operating support and a peripheral circuit environment that matches the chip specifications. For example, it can provide a clock reference by configuring a crystal oscillator, ensure signal stability by setting a current limiting resistor, and achieve signal characteristic matching and adjustment by matching circuit, load circuit or signal conditioning circuit. This enables the chip under test to operate in a circuit environment that meets its operating requirements and ensures the validity and consistency of the test results.

[0029] In this embodiment, the power supply circuit of the chip under test provides operating power to the substrate of the chip under test, thereby enabling the chip under test to have stable power supply conditions to support the operation of the test process; the first auxiliary test circuit provides general test load and standardized peripheral function support, thereby enabling the control chip to execute the corresponding test drive and obtain the response of the chip under test under unified test conditions; the second auxiliary test circuit provides the peripheral circuit support required for the operation of the chip under test, thereby enabling the chip under test to perform the test process in a circuit environment that meets its working requirements; based on this, in the entire technical solution, through the synergistic effect of power supply support, general test support and peripheral circuit support, the stable construction and unified support of the test environment are realized, thereby ensuring the smooth progress of the test process.

[0030] In one exemplary embodiment, the software host computer is configured as follows: When executing the current test case in the firmware library test program, determine whether to switch to the next test case or execute a loop test based on the test result of the current test case; After all test cases in the firmware library test program have been executed, a test report is generated, which includes the test results, actual measured values, and reasons for any anomalies for each test case.

[0031] For example, during the execution of the firmware library test program, the host computer receives and parses the test results corresponding to the current test case, and compares these results with the pre-set result data in the test case. The result data characterizes the output that the test case should produce under normal execution conditions. After comparison, if the test result matches the result data, it indicates that the function corresponding to the test case is executed correctly. At this point, the host computer switches to the next test case according to the preset execution order in the test program to continue executing subsequent tests. If the test result does not match the result data, it indicates that there is an anomaly or unstable output during the execution of the current test case. In this case, the host computer maintains the execution state of the current test case and re-triggers the execution process of the test case, thus entering a loop test to re-execute the test case under the same test conditions and obtain new test results. During subsequent executions, the new test results are continuously compared until they match the pre-set result data or the preset number of loop executions is completed, thereby controlling the test case execution flow.

[0032] For example, after confirming that all test cases in the firmware library test program have been executed, the software host computer summarizes the test results, actual measured values, and reasons for exceptions generated during the execution of each test case. The test results represent the identifiers obtained after the execution of each test case, reflecting whether the corresponding function was executed correctly, such as pass or fail. Actual measured values ​​represent the output data of the chip under test acquired by the control chip during the test, reflecting the specific output of the chip under test when performing the corresponding function, such as the sent data content or pin level values. Reasons for exceptions represent the information recorded for the specific reasons leading to a fail test result, such as incorrect function return values ​​or inconsistent output data. After classifying and organizing the above data, the software host computer associates and organizes the test results, actual measured values, and reasons for exceptions according to a preset format. For example, it arranges and combines the corresponding test content according to the test case number, so that each test case corresponds to a complete set of data content, and generates a test report accordingly, thus forming a data record of the entire testing process.

[0033] Optionally, the test log also includes records of relevant operations performed by the control chip during the test, which reflect its scheduling and driving behavior in the test process, such as the switching of control circuit connections, the execution of output test stimulus signals, and the execution order of corresponding test cases.

[0034] In this embodiment, on the one hand, the software host computer controls the sequential switching or cyclic execution of test cases based on the test results of the current test cases, thereby realizing the sequential advancement of the test process and the control of repeated execution of abnormal test cases; on the other hand, the software host computer summarizes and organizes the test results, actual measurement values ​​and abnormal causes of all test cases and generates a test report, thereby realizing the unified recording and associated presentation of the test content of each test case; based on this, in the entire technical solution, through the dynamic control of the test execution process and the summary processing of test content, the orderly management of the test process and the standardized output of test results are realized.

[0035] In one exemplary embodiment, the software host computer is configured to generate control chip code and chip code under test based on the model of the chip under test.

[0036] The control chip code is used as test control and hardware scheduling logic to realize data interaction between the software host computer and the chip under test, and to schedule the test process to control the control chip to perform test drive and response acquisition on the chip under test.

[0037] The code of the chip under test is used as the logic for test execution and result judgment. It calls the firmware library interface to perform test operations, and verifies the functionality and performance of the firmware library to output test results.

[0038] For example, after the host computer generates control chip code and writes it into the control chip, this control chip code handles the data interaction between the host computer and the chip under test during operation, and schedules and controls the test process. Essentially, the control chip code parses the control information corresponding to the current test case and transforms it into specific hardware control actions. For instance, when executing a serial port transmission function test case, the control chip code controls the corresponding pin to output serial data as a test stimulus signal according to the test requirements. After the chip under test performs the transmission operation, it receives the output data through the corresponding pin and buffers it to form a response signal. As another example, when executing a pin control function test case, the control chip code outputs high and low level signals to relevant pins according to the test requirements and collects and records the changes in the pin states of the chip under test. This method enables programmable control of the test board circuit, allowing the execution content based on test cases to be transformed into specific signal output and acquisition processes, thereby completing the execution of test driving and response acquisition.

[0039] For example, after the host computer generates the code for the chip under test (DUT) and writes it into the DUT, this DUT code serves as the carrier for test execution and result judgment during operation. It calls and executes the firmware library test case set, essentially calling each functional interface in the firmware library one by one according to the test case set, covering all functional branches under different calling conditions. For instance, when executing the serial port transmission function test case, the DUT code calls the corresponding transmission interface to output preset data and obtains its return value and output status to form the corresponding test data. Similarly, when executing the pin control function test case, the DUT code calls the corresponding interface to configure and control the pins, reads relevant status information, and outputs preset test stimulus signals to the control chip according to the test case requirements. After obtaining the above data, the DUT code compares it with the pre-set result data in the test case to determine the execution status of each interface under different calling conditions. By using the above method, the test case set can cover the execution process of each functional interface of the firmware library under different calling conditions, and the corresponding test results can be judged one by one, thereby completing the execution and result judgment of the firmware library testing process.

[0040] In this embodiment, on the one hand, the control chip code is used as the test control and hardware scheduling logic, thereby realizing the transformation of the execution content corresponding to the test cases into the test drive and response acquisition process at the code level; on the other hand, the code of the chip under test is used as the test execution and result judgment logic, thereby forming test results corresponding to each test case at the code level. Based on this, in the entire technical solution, through the division of labor and cooperation between the control chip code and the code of the chip under test, the collaborative processing of test process control, test execution and result judgment is realized, thereby completing the overall execution of the firmware library test process at the code level.

[0041] In one exemplary embodiment, the control chip is configured to: Based on different test cases in the firmware library test program, the control switch matrix circuit selects different line connections so that different pins and peripherals in the chip under test corresponding to each test case participate in the test in sequence. During the sequential execution of test cases, comprehensive testing of each pin under test and peripheral device in the chip under test is gradually achieved.

[0042] For example, when the control chip executes the firmware library test program, it determines the pins or peripheral types of the chip under test (DUT) to be tested based on the test content corresponding to the current test case, and controls the switch matrix circuit accordingly to select the appropriate line connections. These line connections establish signal transmission paths between the control chip and the DUT, forming different types of connections depending on the test object. For instance, when the test case corresponds to a pin input / output function, the selected line connection is between the control chip pin and the general-purpose input / output pin of the DUT, used to transmit high and low level signals; when the test case corresponds to a serial communication function, the selected line connection is between the control chip pin and the communication interface pin of the DUT, used to transmit serial data in a preset format; when the test case corresponds to an analog signal acquisition function, the selected line connection is between the control chip output and the analog input pin of the DUT, used to provide analog voltage signals; and when the test case corresponds to a timing-related function, the selected line connection is between the control chip pin and the corresponding pin of the DUT, used to transmit signals with periodic characteristics.

[0043] For example, during the sequential execution of test cases in the firmware library test program, the control chip, based on the line connection selection results corresponding to each test case, causes the pins or peripherals in the chip under test related to the current test case to enter the corresponding test state. During the execution of each test case, a matching test stimulus signal is applied to the corresponding pin or peripheral through the selected line connection to trigger the execution of the corresponding test operation. After the current test case is completed, the control chip switches the line connection according to the test content of the next test case, causing the new pin or peripheral to enter the test state, and applies the corresponding test stimulus signal in the same way, thereby achieving gradual switching of the test object between different test cases. During the continuous execution of the entire test case set, through the continuous scheduling of each test case, different pins and peripherals in the chip under test participate in the test sequentially in their respective test phases and complete the corresponding functional execution in the corresponding phase, thereby achieving gradual coverage of each pin and peripheral under test in the chip under test.

[0044] Furthermore, in this technical solution, the line connection relationship of the switch matrix circuit is pre-designed to cover multiple pin combinations, so there is no need to adjust its circuit structure when adding a new type of chip under test; the control program built into the control chip is used to receive control information sent by the software host computer and convert it into control operations for the switch matrix circuit. That is, the control chip sends control data to the switch matrix circuit through the SPI bus to realize the selection and switching of the corresponding line connection, so that the system can adapt to different types of chips under test through program configuration.

[0045] In this embodiment, on the one hand, the control chip controls the switch matrix circuit to select the corresponding type of line connection according to different test cases, so that the pins and peripherals in the chip under test that correspond to the test cases can establish a matching connection relationship, thereby enabling each test object to have the connection conditions to participate in the test in the corresponding test stage; on the other hand, the line connection is switched step by step according to the sequential execution of the test cases, so that different pins and peripherals in the chip under test enter the test state in each test stage in turn, thereby realizing the step-by-step participation of each test object; based on this, in the whole technical solution, by selecting the line connection on demand and switching it sequentially during the test process, the orderly access and step-by-step coverage of different pins and peripherals in the chip under test are realized.

[0046] In one exemplary embodiment, the workflow of this system is described by taking the testing of the UART peripheral function in a certain BSP package as an example.

[0047] During the test preparation phase, after the BSP developers complete the development of the UART driver library for the corresponding microcontroller, the testers, based on the chip specifications and BSP function interfaces, write a set of test cases in the test project using the Unity framework. The test case set includes basic test cases and combined test cases. Basic test cases are used to verify the functionality of a single function, such as testing the input parameters and checking the settings of the corresponding bits for the TX pin enable function UART_TXCmd(). Combined test cases are used to jointly verify multiple functions, such as verifying the transmission result of the UART transmission function by sending data of different lengths and contents, combined with data obtained from the control chip.

[0048] During the hardware connection phase, the test baseboard is connected to the substrate of the chip under test to establish a test path between the control chip and the chip under test.

[0049] During the program burning stage, the corresponding chip model under test is selected through the software host computer, and the firmware library test program containing the test case set is written into the control chip and the chip under test respectively through the burning interface, so that the two run under the same test logic.

[0050] During the test execution and interaction phase, after the control chip completes the configuration of the switch matrix circuit, it notifies the chip under test (DUT) that the current test environment has been established via an independent communication interface. Upon receiving this information, the Unity test framework in the DUT automatically calls and executes all test cases related to the UART peripheral. For the transmission function test, data is sent from the transmit pin of the DUT and transmitted to the receive pin of the control chip through the switch matrix circuit. The control chip receives the data and saves it in the receive buffer, waiting for the DUT to retrieve the data in the receive buffer through interactive commands for comparison to determine if the DUT's transmission function is correct.

[0051] During the result determination and reporting phase, the control chip triggers the signal excitation according to the interactive command issued by the chip under test or receives the preset excitation from the chip under test, and reports the data and excitation involved in its own test process; the chip under test completes the test result determination based on the data obtained from the control chip, and transmits the test result back to the software host computer through the switch matrix circuit.

[0052] During the loop and reporting phase, after all UART peripheral-related test cases have been executed, the host computer organizes the test results, actual measurement values, and reasons for anomalies for each test case, generates corresponding test reports, and determines whether to execute loop testing or proceed to the next test process based on the preset configuration.

[0053] Through the above implementation process, automated testing of the microcontroller firmware library, from software logic to hardware functions, is achieved. For testing other peripheral functions, the control chip can provide corresponding test conditions, such as providing analog voltage signals for ADC, obtaining the frequency and duty cycle for PWM, and implementing high and low level input / output tests for GPIO, thereby expanding the testing scope of this system.

[0054] In one exemplary embodiment, Figure 3 The diagram shows the circuit connection and switching between the control chip and the chip under test in the test baseboard, which is used to realize the signal interaction and test path establishment between the control chip and the chip under test through multi-channel signal connection and circuit distribution. Figure 4 The diagram shows the structure of the control chip pinout and interface connection, which is used to bring out the functional pins of the control chip in a unified manner and establish a connection with the external test circuit to support the test drive and data interaction process. Figure 5 The diagram shows the structure of the CAN bus communication interface circuit, which is used to realize signal conversion and communication connection between the control chip and the CAN bus to support the execution of CAN communication test cases; Figure 6 A schematic diagram of an analog signal detection circuit is shown, which is used to filter and stabilize analog input signals to support the execution of ADC-related test cases; Figure 7 A schematic diagram of the LIN bus communication interface circuit is shown, which is used to realize signal conversion and communication connection between the control chip and the LIN bus to support the execution of LIN communication test cases; Figure 8 The diagram shows the structure of a power supply processing circuit, which is used to filter, decouple, and regulate the input power supply to provide a stable operating power supply for the control chip and related test circuits.

[0055] Furthermore, the above Figures 5 to 8The circuits shown are all set on the test baseboard. The CAN bus communication interface circuit, analog signal detection circuit, and LIN bus communication interface circuit serve as the first auxiliary test circuit to provide standardized test conditions, while the power supply circuit serves as the power supply circuit to provide stable power to each module of the test baseboard.

[0056] Based on the same inventive concept, this application also provides an automated testing method for a microcontroller firmware library applied to the automated testing system of the aforementioned microcontroller firmware library. The solution provided by this method is similar to the implementation scheme described in the above system; therefore, the specific limitations in one or more method embodiments provided below can be found in the limitations of the automated testing system for the microcontroller firmware library described above, and will not be repeated here.

[0057] In one embodiment, such as Figure 9 As shown, an automated testing method for a microcontroller firmware library is provided. This embodiment illustrates the application of this method to an automated testing system for a microcontroller firmware library in any of the above embodiments. The system includes a software host computer, a test baseboard, and a chip substrate under test, which are sequentially and communicatively connected. The test baseboard includes a control chip and a switch matrix circuit. The chip substrate under test includes the chip under test. The switch matrix circuit is connected to both the control chip and the chip under test, and selects the connection between them.

[0058] In this embodiment, the method includes the following steps S101 to S103.

[0059] Step S101: The host computer generates a firmware library test program based on the model of the chip under test, and downloads it to the control chip and the chip under test. In step S102, after the control chip controls the switch matrix circuit to select the corresponding line connection according to the firmware library test program, the chip under test runs the firmware library test program, and the control chip performs test driving and response acquisition on the chip under test. In step S103, the chip under test determines the test result based on the response collected by the control chip, and uploads the test result to the software host computer through the control chip.

[0060] In an exemplary embodiment, the test baseboard further includes a power supply circuit for the chip under test and a first auxiliary test circuit, and the chip under test substrate further includes a second auxiliary test circuit; the power supply circuit for the chip under test provides operating power to the chip under test substrate; the first auxiliary test circuit provides general test load and standardized peripheral function support; the second auxiliary test circuit provides peripheral circuit support required for the operation of the chip under test.

[0061] In one exemplary embodiment, the firmware library tester includes a BSP firmware library and test cases generated by a test framework.

[0062] In an exemplary embodiment, the testing framework is used to perform the following steps: providing a unified specification for writing test cases; executing test cases and generating test results, and performing consistency verification on the test results according to the assertion mechanism; and sending the test results to the control chip and the software host computer through a preset communication channel.

[0063] In an exemplary embodiment, the software host computer is used to perform the following steps: when executing the current test case in the firmware library test program, determine whether to switch to the next test case or execute a loop test based on the test result of the current test case; after executing all test cases in the firmware library test program, generate a test report, which includes the test results, actual measurement values ​​and reasons for exceptions for each test case.

[0064] In an exemplary embodiment, the peripherals that drive the test of the chip under test by the control chip include at least one of GPIO, UART, SPI, ADC, and timer. The test stimulus signals generated by the peripherals include at least one of high and low levels, PWM waves, serial data of a preset protocol, and analog voltage.

[0065] In an exemplary embodiment, the software host computer is used to perform the following steps: generating control chip code and chip code under test according to the model of the chip under test; the control chip code is used as test control and hardware scheduling logic to realize data interaction between the software host computer and the chip under test, and to schedule the test process to control the control chip to perform test drive and response acquisition on the chip under test; the chip code under test is used as test execution and result judgment logic to call the firmware library interface to perform test operations, and to verify the function and performance of the firmware library to output test results.

[0066] In an exemplary embodiment, the control chip is used to perform the following steps: according to different test cases in the firmware library test program, control the switch matrix circuit to select different line connections so that different pins and peripherals in the chip under test corresponding to each test case participate in the test in sequence; during the sequential execution of the test cases, the coverage test of each pin and peripheral in the chip under test is gradually realized.

[0067] In an exemplary embodiment, the line connection between the transmit pin of the chip under test (DUT) and the receive pin of the control chip is used to perform the following steps: transmitting the response signal output by the DUT when running the firmware library test program to the control chip and storing it; the line connection between the receive pin of the DUT and the transmit pin of the control chip is used to perform the following steps: sending the test stimulus signal output by the control chip to the DUT, and sending the response signal stored by the control chip to the DUT, so that the DUT can determine the test result based on the response signal.

[0068] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0069] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods.

[0070] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0071] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. An automated testing system for a microcontroller firmware library, characterized in that, The system includes a software host computer, a test baseboard, and a chip substrate that are sequentially and communicatively connected. The test baseboard includes a control chip and a switch matrix circuit. The chip under test substrate includes the chip under test. The switch matrix circuit is connected to the control chip and the chip under test respectively, and selects the circuit connection between the two. The system is configured as follows: The host computer generates a firmware library test program based on the model of the chip under test, and downloads it to the control chip and the chip under test. After the control chip controls the switch matrix circuit to select the corresponding line connection according to the firmware library test program, the chip under test runs the firmware library test program, and the control chip performs test driving and response acquisition on the chip under test. The chip under test determines the test results based on the response collected by the control chip, and uploads the test results to the software host computer through the control chip.

2. The system according to claim 1, characterized in that, The test base plate also includes a power supply circuit for the chip under test and a first auxiliary test circuit, and the chip under test substrate also includes a second auxiliary test circuit. The power supply circuit of the chip under test is connected to the substrate of the chip under test and is used to provide working power to the substrate of the chip under test. One end of the first auxiliary test circuit is connected to the control chip, and the other end is connected to the chip under test or the second auxiliary test circuit via the switch matrix circuit, which is used to provide general test load and standardized peripheral function support; The second auxiliary test circuit is connected to the chip under test and is used to provide the peripheral circuit support required for the operation of the chip under test.

3. The system according to claim 1, characterized in that, The firmware library test program includes the BSP firmware library and test cases generated by the test framework.

4. The system according to claim 3, characterized in that, The testing framework is configured as follows: Provide a unified writing standard for the test cases; Execute the test cases and generate test results, and perform consistency verification on the test results according to the assertion mechanism; The test results are sent to the control chip and software host computer through a preset communication channel.

5. The system according to claim 1, 3, or 4, characterized in that, The software host computer is configured as follows: When executing the current test case in the firmware library test program, determine whether to switch to the next test case or execute a loop test based on the test result of the current test case; After all test cases in the firmware library test program have been executed, a test report is generated, which includes the test results, actual measured values, and reasons for any anomalies for each test case.

6. The system according to claim 1 or 3, characterized in that, The peripherals that drive the test of the chip under test by the control chip include at least one of GPIO, UART, SPI, ADC, and timer. The test excitation signals generated by the peripherals include at least one of high and low levels, PWM waves, serial data of a preset protocol, and analog voltage.

7. The system according to claim 1, characterized in that, The software host computer is configured as follows: Generate the control chip code and the chip code under test based on the model of the chip under test; The control chip code is used as test control and hardware scheduling logic to realize data interaction between the software host computer and the chip under test, and to schedule the test process to control the control chip to perform test drive and response acquisition on the chip under test. The code of the chip under test is used as the test execution and result judgment logic to call the firmware library interface to perform test operations, verify the functionality and performance of the firmware library, and output test results.

8. The system according to claim 1, characterized in that, The control chip is configured as follows: According to different test cases in the firmware library test program, the switch matrix circuit is controlled to select different line connections so that different pins and peripherals in the chip under test corresponding to each test case participate in the test in sequence. During the sequential execution of the test cases, the coverage test of each pin under test and peripheral device in the chip under test is gradually realized.

9. The system according to claim 1, characterized in that, The switch matrix circuit is connected to the transmit pin of the chip under test and the receive pin of the control chip, and is also connected to the receive pin of the chip under test and the transmit pin of the control chip, and selects the line connection between the pins. The line connection between the transmit pin of the chip under test and the receive pin of the control chip is used to transmit the response signal output by the chip under test when running the firmware library test program to the control chip and store it. The line connection between the receive pin of the chip under test and the transmit pin of the control chip is used to send the test excitation signal output by the control chip to the chip under test, and to send the response signal stored by the control chip to the chip under test, so that the chip under test can determine the test result based on the response signal.

10. An automated testing method for a microcontroller firmware library, characterized in that, The method is applied to the automated testing system of the microcontroller firmware library according to any one of claims 1 to 9; The method includes: The host computer generates a firmware library test program based on the model of the chip under test, and downloads it to the control chip and the chip under test. After the control chip controls the switch matrix circuit to select the corresponding line connection according to the firmware library test program, the chip under test runs the firmware library test program, and the control chip performs test driving and response acquisition on the chip under test. The chip under test determines the test results based on the response collected by the control chip, and uploads the test results to the software host computer through the control chip.

Images