Method and system for testing Flash model in MCU (Microprogrammed Control Unit) based on ATE (Advanced Technology Equipment)

Abstract

The invention provides a method and a system for testing a Flash model in an MCU (Microprogrammed Control Unit) based on ATE (Automatic Train Equipment). The method comprises the following steps of: obtaining a Flash drive program file and a test data file; the Flash drive program file is analyzed, and a Flash drive program is obtained; writing the Flash driving program into the MCU to be tested; a test data file corresponding to the Flash drive program is written into the MCU to be tested; and based on the written Flash drive program and the test data file, completing the test of the to-be-tested MCU. The invention provides a method and a system for testing a Flash model in an MCU (Microprogrammed Control Unit) based on ATE (Advanced Technology Equipment), which can effectively solve the problems of large workload, long development time and limited efficiency when Flash models in different MCUs are tested, and have relatively high adaptability and flexibility.

Description

Technical Field

[0001] The present invention relates to the technical field of MCU chip testing, and in particular to a Flash model testing method and system in an MCU based on ATE equipment. Background Art

[0002] MCU chip testing refers to various tests and verification processes for microcontrollers to ensure that their functions, performance and reliability meet the design requirements. MCU has multiple functional modules that need to be tested, such as RAM module, GPIO module, timer module, Flash module, etc. Among them, FLASH is a non-volatile memory commonly used in microcontrollers (MCU), mainly used to store program code and some configuration data. FLASH can still retain data after power failure, so it is suitable for applications that need to retain information after the device is restarted. Therefore, Flash will affect the reliability and stability of the MCU, so it is particularly important to test FLASH;

[0003] In the prior art, there are many models and types of MCU chips. Generally speaking, in the process of testing Flash, each signal MCU needs to develop and integrate corresponding different types of Flash test programs, which is a large workload and is far from meeting the market testing needs.

[0004] Therefore, there is a need for a solution to solve at least one of the above problems. Summary of the invention

[0005] In view of the defects in the prior art, the present application proposes a Flash model testing method and system in an MCU based on an ATE device. To solve at least one of the above technical problems, the technical solution of the present application is: a Flash model testing method in an MCU based on an ATE device, comprising:

[0006] Get the Flash driver file and test data file;

[0007] Parse the Flash driver file to obtain the Flash driver;

[0008] Write the Flash driver to the MCU to be tested;

[0009] Then write the test data file corresponding to the Flash driver into the MCU to be tested;

[0010] Based on the written Flash driver and test data file, the Flash model in the MCU to be tested is tested.

[0011] In a specific embodiment, based on the written Flash driver and test data file, the process of completing the test of the Flash model in the MCU to be tested specifically includes:

[0012] Select one or more test instructions in the Flash driver and a data group in the test data file pointed to by each test instruction;

[0013] Set the expected output results based on the selected test instructions and data groups;

[0014] Execute the selected test instructions to obtain the actual output results;

[0015] Compare the difference between the expected output result and the actual output result to determine whether the test item corresponding to the test instruction is tested successfully.

[0016] In a specific embodiment, if the test item corresponding to the test instruction fails, the test instruction is re-executed at least once;

[0017] If the test instruction still fails after re-executing the test instruction at least once, the test failure result is recorded;

[0018] The result of a test failure includes recording the type of error, the actual output result and the expected output result, and one or more of the possible error causes.

[0019] In a specific embodiment, the test instruction includes one or any multiple of a data read instruction, a data write instruction, a data erase instruction, and a data comparison instruction;

[0020] Based on the selected test instructions and data groups, in the process of setting the expected output results, at least the following test instructions are selected for testing, and the following test instructions are executed in sequence:

[0021] Execute the data erase instruction to clear the Flash area of ​​the MCU to be tested;

[0022] According to the data writing instruction, the first data in the test data file is written into the Flash area of ​​the MCU as the second data, wherein the first data is the expected output result and the second data is the actual output result;

[0023] Read the second data written into the Flash area through a data read instruction;

[0024] Establishing a data association between the first data and the second data;

[0025] The second data written into the Flash area is randomly accessed, and a data comparison instruction is used to determine whether the first data is identical to the associated second data.

[0026] In a specific embodiment, when testing the Flash model in the MCU to be tested, the method further includes:

[0027] A test report is generated based on the test result, wherein the test report includes one or any multiple of all test instructions executed, the success rate of each test instruction, and the result of test failure.

[0028] In a specific embodiment, the method further comprises: after completing the test of the Flash model in the MCU to be tested, storing the Flash driver file and the test data file;

[0029] The specific steps of storing the Flash driver file and the test data file include:

[0030] Define the naming format of the Flash driver file, the corresponding MCU type and version number, or any number of them;

[0031] Store the defined Flash driver file and the corresponding test file;

[0032] And record the change history according to the version of the stored Flash driver file.

[0033] In a specific embodiment, when testing a Flash model in a certain type of MCU, the Flash driver file that is preferentially used is the first driver file;

[0034] If a new Flash driver file is obtained, the Flash driver file is compared with the stored Flash driver file;

[0035] When the newly acquired Flash driver file version is newer than the stored Flash driver file, and the newly acquired Flash driver file meets the preset test conditions, the newly acquired Flash driver file is used as the first driver file, and the test data file is updated accordingly;

[0036] If the newly acquired Flash driver file does not meet the preset test condition, the next newest Flash driver file is used as the first driver file, and the newly acquired Flash driver file is stored.

[0037] In a specific embodiment, the Flash driver file includes one or more, and the test data file includes one or more;

[0038] The method further includes: if the Flash driver program file and the test data file are not obtained, testing the Flash based on the Flash driver program file and the corresponding test data file obtained historically.

[0039] A Flash model testing system in an MCU based on ATE equipment, comprising:

[0040] An acquisition module is used to acquire Flash driver files and test data files;

[0041] A parsing module is used to parse the Flash driver file to obtain the Flash driver;

[0042] A writing module is used to write the Flash driver into the MCU to be tested, and then write the test data file corresponding to the Flash driver into the MCU to be tested;

[0043] The test module is used to complete the test of the Flash model in the MCU to be tested based on the written Flash driver and test data file.

[0044] In a specific embodiment, the system further comprises:

[0045] A storage module is used to store the Flash driver file and the test data file after completing the test of the Flash to be tested;

[0046] The specific steps of storing the Flash driver file and the test data file include:

[0047] Define the naming format of the Flash driver file, the corresponding MCU type and version number, or any number of them;

[0048] Store the defined Flash driver file and the corresponding test file;

[0049] And record the change history according to the version of the stored Flash driver file.

[0050] Beneficial effects:

[0051] The present invention provides a method and system for testing a Flash model in an MCU based on an ATE device, which can effectively solve the problems of heavy workload, long development time and limited efficiency when testing Flash models in different MCUs, and has strong adaptability and flexibility;

[0052] Specifically, the test process is separated from the Flash driver process, which effectively shortens the Flash test time and can test the Flash models in different types of MCUs. It has strong versatility and does not need to integrate various Flash test programs separately, reducing the operating burden of the test system. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without creative work.

[0054] Figure 1 The process diagram of a Flash model testing method in an MCU based on an ATE device according to an embodiment of the present invention is shown in FIG. Figure 1 ;

[0055] Figure 2 The process diagram of a Flash model testing method in an MCU based on an ATE device according to an embodiment of the present invention is shown in FIG. Figure 2 ;

[0056] Figure 3 A network block diagram of a Flash model testing method in an MCU based on an ATE device according to an embodiment;

[0057] Figure 4 The module composition of the Flash model test system in the MCU based on ATE equipment of an embodiment Figure 1 ;

[0058] Figure 5 The module composition of the Flash model test system in the MCU based on ATE equipment of an embodiment Figure 2 .

[0059] Reference numerals:

[0060] 1-acquisition module; 2-analysis module; 3-writing module; 4-testing module; 5-storage module. DETAILED DESCRIPTION

[0061] In the following, various embodiments of the present disclosure will be described more fully. The present disclosure may have various embodiments, and adjustments and changes may be made therein. However, it should be understood that there is no intention to limit the various embodiments of the present disclosure to the specific embodiments disclosed herein, but rather the present disclosure should be understood to cover all adjustments, equivalents and / or alternatives that fall within the spirit and scope of the various embodiments of the present disclosure.

[0062] Hereinafter, the terms "include" or "may include" used in various embodiments of the present disclosure indicate the presence of disclosed functions, operations, or elements, and do not limit the addition of one or more functions, operations, or elements. In addition, as used in various embodiments of the present disclosure, the terms "include", "have", and their cognates are intended only to indicate specific features, numbers, steps, operations, elements, components, or a combination of the foregoing, and should not be understood as first excluding the presence of one or more other features, numbers, steps, operations, elements, components, or a combination of the foregoing or the possibility of adding one or more features, numbers, steps, operations, elements, components, or a combination of the foregoing.

[0063] In various embodiments of the present disclosure, the expression "or" or "at least one of A or / and B" includes any combination or all combinations of the words listed at the same time. For example, the expression "A or B" or "at least one of A or / and B" may include A, may include B, or may include both A and B.

[0064] The expressions (such as "first", "second", etc.) used in the various embodiments of the present disclosure may modify the various constituent elements in the various embodiments, but may not limit the corresponding constituent elements. For example, the above expressions do not limit the order and / or importance of the elements. The above expressions are only used for the purpose of distinguishing one element from other elements. For example, the first user device and the second user device indicate different user devices, although both are user devices. For example, without departing from the scope of the various embodiments of the present disclosure, the first element may be referred to as the second element, and similarly, the second element may also be referred to as the first element.

[0065] It should be noted that if it is described that one component element is “connected” to another component element, the first component element may be directly connected to the second component element, and a third component element may be “connected” between the first component element and the second component element. Conversely, when one component element is “directly connected” to another component element, it can be understood that there is no third component element between the first component element and the second component element.

[0066] The term “user” used in various embodiments of the present disclosure may indicate a person using an electronic device or a device (eg, an artificial intelligence electronic device) using the electronic device.

[0067] The terms used in the various embodiments of the present disclosure are only used for the purpose of describing specific embodiments and are not intended to limit the various embodiments of the present disclosure. As used herein, the singular form is intended to also include the plural form, unless the context clearly indicates otherwise. Unless otherwise defined, all terms (including technical terms and scientific terms) used herein have the same meaning as the meanings commonly understood by ordinary technicians in the field to which the various embodiments of the present disclosure belong. The terms (such as the terms defined in the generally used dictionary) will be interpreted as having the same meaning as the contextual meaning in the relevant technical field and will not be interpreted as having an idealized meaning or an overly formal meaning, unless clearly defined in the various embodiments of the present disclosure.

[0068] Example 1

[0069] The present application embodiment proposes a Flash model testing method in an MCU based on an ATE device, such as Figure 1 and Figure 3 As shown, including:

[0070] S100, obtaining a Flash driver file and a test data file;

[0071] For example, the driver file and the corresponding test data file of the Flash model in the MCU in the project can be obtained from an integrated development environment such as Keil, IAR, etc.; Flash driver files of different models can also be obtained from a cloud storage database through network access;

[0072] Of course, there is no limitation on the method of obtaining the Flash driver file and the test data file.

[0073] The driver file of the Flash model in each MCU is provided with a matching test data file. The test data file corresponding to each driver file can be recorded by creating a configuration file; or, the association information of the driver file and the test data file can be stored by a database storage method (such as SQLite, MySQL, etc.); so as to achieve a good correspondence between the Flash driver file and the test data file.

[0074] S200, parsing the Flash driver file to obtain the Flash driver;

[0075] ATE test equipment is automated test equipment. Flash refers specifically to the functional module or functional area of ​​MCU. Parsing Flash driver files generally requires steps such as file format identification and reading file contents.

[0076] Among them, file format identification refers to determining the format of the Flash driver file, such as Intel HEX, Motorola S-record and Binary formats, so as to adopt different parsing methods for different formats to meet the needs of testing different models of Flash.

[0077] Understandably, during the parsing process, test information can be extracted, which helps to perform functional testing and troubleshooting in a simulation environment, and promptly discover and fix potential defects; by parsing and recording different versions of drivers, effective test drive version management can be performed to reduce the possibility of test errors.

[0078] S300, write the Flash driver into the MCU to be tested;

[0079] S400, then write the test data file corresponding to the Flash driver into the MCU to be tested;

[0080] Specifically, in some embodiments of the present application, the ATE test equipment writes the Flash drive system and the corresponding test data file into the RAM module of the MCU chip through the SWD / JTAG interface;

[0081] It is understandable that writing the Flash driver usually initializes the MCU system status and hardware resources. By writing the Flash driver first and then writing the test data file, the mismatch between the data and the uninitialized or error-state hardware can be reduced, the impact on the test results can be reduced, and the possibility of successful Flash testing can be further increased.

[0082] Writing the driver and test data into the MCU RAM for execution reduces the possibility of errors in the test process, and can give full play to the speed advantage of the MCU RAM, improve test efficiency, and can also be applied to more complex test steps;

[0083] Placing the test logic in the MCU RAM for execution can avoid frequent Flash read and write operations, thereby extending the life of the Flash and reducing resource waste.

[0084] S500 completes the test of the Flash model in the MCU to be tested based on the written Flash driver and test data file.

[0085] Through the above-mentioned testing methods, the flexibility, accuracy and efficiency of existing testing methods can be enhanced, the overall testing integration level can be improved, targeted debugging can be carried out, the limiting impact of the inherent testing framework can be reduced, regression testing can be completed quickly, and stability and reliability can be improved.

[0086] Furthermore, based on the written Flash driver and the test data file, the process of completing the test of the Flash to be tested specifically includes:

[0087] Select one or more test instructions in the Flash driver and a data group in the test data file pointed to by each test instruction;

[0088] Specifically, in some embodiments of the present application, different data groups have different data modes, such as all 0s, all 1s, random data, etc., to detect the stability and reliability of the Flash. Different test instructions point to data groups with different data modes according to characteristics, and different test instructions are tested using different data groups.

[0089] Exemplarily, the test instructions and the corresponding data groups can be randomly sampled by random selection to facilitate rapid inspection of the stability and reliability of the Flash; or the test instructions with a high error frequency can be selected in a targeted manner for key testing based on the historical test data of the Flash model in the MCU of this model;

[0090] Of course, there is no limitation on the selection method of the specific test instruction.

[0091] Set the expected output results based on the selected test instructions and data groups;

[0092] Execute the selected test instructions to obtain the actual output results;

[0093] Compare the difference between the expected output result and the actual output result to determine whether the test item corresponding to the test instruction is tested successfully.

[0094] Specifically, the comparison between the expected output result and the actual output result can be achieved by setting a comparison function. By comparing each field or data point between the actual output and the expected output item by item, a tolerance can be set for the difference. For example, for floating-point numbers or approximate values, a tolerance range can be set to determine whether the actual output is within the expected range.

[0095] More specifically, the test of the Flash model in the MCU to be tested may include functional operation test and functional condition test; functional operation test, selecting test instructions to verify whether the read, write, and erase functions of the Flash operate normally; functional condition test, selecting test instructions to test the boundary conditions of the Flash, such as the maximum and minimum addresses.

[0096] Based on the written Flash driver and test data file, completing the test of the MCU to be tested may also include: initializing the test environment, preparing and loading a test script or configuration file according to the test requirements.

[0097] By using a driver designed specifically for the Flash model in the MCU, it helps to ensure that the operations during the test are consistent with the actual behavior of the hardware, thereby improving the accuracy of the test results; the test data file contains predefined inputs and expected outputs, which helps to systematically verify whether the Flash functions as expected and is used to discover potential design defects in the Flash; automation through scripted test processes also improves test efficiency; and during the test process, hardware or software problems can be identified in a timely manner, and fault analysis can be performed through recorded logs and outputs to help quickly locate and fix problems.

[0098] Further, if the test item corresponding to the test instruction fails, the test instruction is re-executed at least once;

[0099] If the test instruction still fails after re-executing the test instruction at least once, the test failure result is recorded;

[0100] It can be understood that by re-executing the test instruction at least once, it can help determine whether the problem is an accidental error, reduce the impact of accidental factors, and thus improve the accuracy of the test results.

[0101] The result of a test failure includes recording the type of error, the actual output result and the expected output result, and one or more of the possible error causes.

[0102] Understandably, the results of test failures include recording the error type, actual output, and expected output, which can track the problems that occur, help quickly locate the problems, and facilitate subsequent analysis and repair; by analyzing failed test cases, you can find the deficiencies in the test cases, thereby optimizing and improving test strategies and test cases, and improving test coverage and effectiveness; by establishing an error record library, it helps to accumulate knowledge intelligently and avoid similar errors from happening again in the future; regularly reviewing the results of test failures helps to improve code quality.

[0103] Further, the test instruction includes one or any multiple of a data read instruction, a data write instruction, a data erase instruction, and a data comparison instruction;

[0104] like Figure 2 As shown, based on the selected test instructions and data groups, in the process of setting the expected output results, at least the following test instructions are selected for testing, and the following test instructions are executed in sequence:

[0105] S501, execute a data erase instruction to clear the Flash area of ​​the MCU to be tested;

[0106] By executing the data erase instruction, the Flash area is reset, which helps to keep the Flash area of ​​the MCU to be tested clean, thereby avoiding the interference of old data on the test results;

[0107] S502, according to the data writing instruction, write the first data in the test data file into the Flash area of ​​the MCU as the second data; wherein the first data is the expected output result, and the second data is the actual output result;

[0108] Writing the first data in the test data file into the MCU and using it as the expected output result helps to accurately verify the actual output result in subsequent steps.

[0109] S503, reading the second data written into the Flash area through a data read instruction;

[0110] S504, establishing a data association between the first data and the second data;

[0111] Establishing the association between the first data and the second data is conducive to tracking the test results of each step and facilitating subsequent analysis and debugging;

[0112] S505 , randomly access the second data written into the Flash area, and use a data comparison instruction to determine whether the first data is identical to the associated second data.

[0113] Through the data reading and comparison steps, the data consistency in the Flash area can be systematically verified, which significantly reduces the possibility of data loss or change during the writing and reading process. Then, by randomly accessing and comparing data, it helps to quickly discover and locate problems, improve fault location capabilities, and increase troubleshooting efficiency. In addition, through comprehensive step design, more test scenarios can be covered. Detailed records of the execution process and results of each step will help with subsequent test reproduction and result verification, promote documentation and reproducibility, and provide reliable document support for test projects.

[0114] Furthermore, when testing the Flash model in the MCU to be tested, the method further includes:

[0115] A test report is generated based on the test results. The test report includes one or any multiple of all test instructions executed, the success rate of each test instruction, and the result of test failure.

[0116] Specifically, in some embodiments of the present application, the process of generating a test report can follow the following steps: generate an introduction section, the introduction section includes the test objectives and scope and the test environment, the test environment specifically includes a description of the hardware and software environment and version information used to perform the test; summarize the test instructions, including all executed test instructions and functional descriptions; record the test results, including the test instruction name, execution time, success rate, etc.; analyze errors, summarize the reasons for failure, real-time output of failure or real-time screenshots, and propose solutions.

[0117] It can be understood that the test report of the above method covers all test instructions, the success rate of each test instruction, the results of test failures, and error result analysis, which is convenient for the improvement of subsequent tests and enhances the adaptability of the test system. For example, if the cause of failure or error is: the input data format does not meet expectations, it can be processed by verifying the format of the input data to meet system requirements, or adding an input format check function to catch such errors in advance.

[0118] Further, the method further comprises: after completing the test of the Flash model in the MCU to be tested, storing the Flash driver file and the test data file;

[0119] By defining the naming format and version number of the Flash driver file, different versions of the driver can be managed systematically, making it easier to find and use them later;

[0120] Exemplarily, the specific contents of defining the naming format and version number of the Flash driver file include but are not limited to setting a version identifier for each version of the Flash driver file, recording parameters of each version of the Flash driver file, and defining a calling method of the Flash driver file, etc. The version identifier may be, for example, "v1", "v2", "v3", ... and so on.

[0121] The specific steps of storing the Flash driver file and the test data file include:

[0122] Define the naming format of the Flash driver file, the corresponding MCU type and version number, or any number of them;

[0123] Store the defined Flash driver file and the corresponding test file;

[0124] And record the change history according to the version of the stored Flash driver file.

[0125] Specifically, in some embodiments of the present application, different folders or database tables are created according to the MCU type, so that each MCU corresponds to an exclusive storage space; a consistent naming convention is adopted, such as "MCU model_version identifier", which is easy to identify and retrieval; a version control system (such as Git) is used to manage the version of the driver and record the change history; detailed documentation is written for the driver of each MCU, explaining the purpose, version and usage; and scripts are written to automatically store the new driver in the corresponding location to reduce manual operation errors.

[0126] By defining the naming format and version identifier of the Flash driver file, different versions of the driver can be managed systematically, which is convenient for subsequent search and use; recording the change history helps to track the modifications of each version, facilitates the understanding of the evolution of historical versions, and rolls back or compares when necessary; storing test data files and driver files can ensure that when problems occur, they can be quickly located and reproduced, thereby improving system reliability; by storing driver files and test data files, data loss can be effectively prevented and the security of key files can be ensured; the process of recording change history and storing files also provides good documentation support, which is helpful for subsequent audits and evaluations.

[0127] Further, when testing a Flash model in a certain type of MCU, the Flash driver file preferentially used is the first driver file;

[0128] If a new Flash driver file is obtained, the Flash driver file is compared with the stored Flash driver file;

[0129] When the newly acquired Flash driver file version is newer than the stored Flash driver file, and the newly acquired Flash driver file meets the preset test conditions, the newly acquired Flash driver file is used as the first driver file, and the test data file is updated accordingly;

[0130] If the newly acquired Flash driver file does not meet the preset test condition, the next newest Flash driver file is used as the first driver file and the newly acquired Flash driver file is stored.

[0131] The next-newest Flash driver file generally refers to the latest Flash driver file that has been stored.

[0132] During this process, updates, additions, and deletions may occur between different versions of the Flash driver files.

[0133] It can be understood that by giving priority to the use of the new version of the Flash driver file, the latest and most optimized driver can be used first, which is convenient for better completion of the Flash test and meets the actual test needs; by making judgments based on the conditions of the obtained driver file, it can also flexibly respond to different test requirements and environmental changes, and improve the adaptability of the overall test; automatically rolling back to the next latest driver file when the new version does not meet the preset conditions can also help reduce failures or problems caused by the use of inappropriate drivers and improve the safety of the test; through strict condition comparison and version control, it can ensure that verified drivers are always used to reduce the system failure rate; the automated version comparison and selection process can reduce manual intervention, improve the efficiency of test execution, and save time and labor costs; comparing and updating the old and new driver files can help maintain a clear version history and make management and auditing more convenient; new drivers that meet the preset test conditions can bring better test results and help the system performance meet the expected standards in actual applications.

[0134] Among them, the preset test conditions are necessary conditions for the smooth conduct of Flash testing, for example, whether the newly acquired Flash driver file can meet the test needs of all current test items, and whether the newly acquired Flash driver file can have good compatibility with the existing system and other drivers.

[0135] Further, the Flash driver file includes one or more, and the test data file includes one or more;

[0136] The method further includes: if the Flash driver program file and the test data file are not obtained, testing the Flash based on the Flash driver program file and the corresponding test data file obtained historically.

[0137] Even if new drivers and test data are not obtained, the above method can still be used for testing based on historical files, ensuring that the test process is not interrupted and improving the continuity of the test; by using historically obtained drivers and test data, existing resources can be fully utilized to reduce duplication of work, save time and cost; in the absence of new versions, the use of historical files can avoid the introduction of unknown problems and reduce the risks caused by the use of immature or incompatible new files; using historical data for testing can help verify the stability and reliability of the system in a known state and ensure that no unexpected failures occur; by continuously using historical files for testing, more test data can be accumulated, which is helpful for subsequent analysis and decision-making; using historical drivers can facilitate regression testing to verify that new functions do not damage existing functions; by quickly calling historical files for testing, the testing process can be accelerated, waiting time can be reduced, and overall efficiency can be improved.

[0138] The MCU mentioned above refers to the microcontroller, SWD / JTAG is the MCU debugging communication bus, RAM is the random access memory, and Flash is the power-off non-volatile memory.

[0139] The embodiments of the present application have at least the following beneficial effects:

[0140] The embodiment of the present application provides a method for testing a Flash model in an MCU based on an ATE device, which can effectively solve the problems of heavy workload, long development time, and limited efficiency when testing Flash models in different MCUs, and has strong adaptability and flexibility;

[0141] Specifically, the test process is separated from the Flash driver process, which effectively shortens the Flash test time and can test the Flash models in different types of MCUs. It has strong versatility and does not need to integrate various Flash test programs separately, reducing the operating burden of the test system.

[0142] Example 2

[0143] The present application embodiment proposes a Flash model testing system in an MCU based on an ATE device, such as Figure 4 As shown, including:

[0144] Acquisition module 1, used to acquire Flash driver file and test data file;

[0145] Parsing module 2, used for parsing the Flash driver file to obtain the Flash driver;

[0146] A writing module 3 is used to write the Flash driver into the MCU to be tested, and then write the test data file corresponding to the Flash driver into the MCU to be tested;

[0147] The test module 4 is used to complete the test of the Flash model in the MCU to be tested based on the written Flash driver and test data file.

[0148] Furthermore, if Figure 5 As shown, the system also includes:

[0149] The storage module 5 is used to store the Flash driver file and the test data file after completing the test of the Flash model in the MCU to be tested;

[0150] The specific steps of storing the Flash driver file and the test data file include:

[0151] Define the naming format of the Flash driver file, the corresponding MCU type and version number, or any number of them;

[0152] Store the defined Flash driver file and the corresponding test file;

[0153] And record the change history according to the version of the stored Flash driver file.

[0154] Since the technical problem to be solved by this embodiment, the technical solution used to solve the technical problem, and the technical effect achieved are the same as those of the above method, the technical details of the system in this embodiment can be found in the above method embodiment 1, and will not be repeated here.

[0155] Those skilled in the art will appreciate that the modules in the device in the implementation scenario can be distributed in the device in the implementation scenario according to the implementation scenario description, or can be changed accordingly and located in one or more devices different from the implementation scenario. The modules in the above implementation scenario can be combined into one module, or can be further split into multiple sub-modules.

[0156] The above serial numbers of the present invention are only for description and do not represent the advantages or disadvantages of the implementation scenarios.

[0157] Disclosed above are only several specific implementation scenarios of the present invention, but the present invention is not limited thereto, and any changes that can be conceived by those skilled in the art should fall within the protection scope of the present invention.

Claims

1. A Flash model testing method in MCU based on ATE equipment, characterized in that: include: Get the Flash driver file and test data file; Parse the Flash driver file to obtain the Flash driver; Write the Flash driver to the MCU to be tested; Then write the test data file corresponding to the Flash driver into the MCU to be tested; Based on the written Flash driver and test data file, the Flash model in the MCU to be tested is tested.

2. The method for testing a Flash model in an MCU based on an ATE device according to claim 1, characterized in that: Based on the written Flash driver and test data file, the process of completing the test of the Flash model in the MCU to be tested specifically includes: Select one or more test instructions in the Flash driver and a data group in the test data file pointed to by each test instruction; Set the expected output results based on the selected test instructions and data groups; Execute the selected test instructions to obtain the actual output results; Compare the difference between the expected output result and the actual output result to determine whether the test item corresponding to the test instruction is tested successfully.

3. The Flash model testing method in MCU based on ATE equipment according to claim 2, characterized in that: If the test item corresponding to the test instruction fails, re-execute the test instruction at least once; If the test instruction still fails after re-executing the test instruction at least once, the test failure result is recorded; The result of a test failure includes recording the type of error, the actual output result and the expected output result, and one or more of the possible error causes.

4. The method for testing a Flash model in an MCU based on an ATE device according to claim 2, characterized in that: The test instruction includes one or any multiple of a data read instruction, a data write instruction, a data erase instruction and a data comparison instruction; Based on the selected test instructions and data groups, in the process of setting the expected output results, at least the following test instructions are selected for testing, and the following test instructions are executed in sequence: Execute the data erase instruction to clear the Flash area of ​​the MCU to be tested; According to the data writing instruction, the first data in the test data file is written into the Flash area of ​​the MCU as the second data, wherein the first data is the expected output result and the second data is the actual output result; Read the second data written into the Flash area through a data read instruction; Establishing a data association between the first data and the second data; The second data written into the Flash area is randomly accessed, and a data comparison instruction is used to determine whether the first data is identical to the associated second data.

5. The method for testing a Flash model in an MCU based on an ATE device according to claim 3, characterized in that: When testing the Flash model in the MCU to be tested, the method further includes: A test report is generated based on the test result, wherein the test report includes one or any multiple of all test instructions executed, the success rate of each test instruction, and the result of test failure.

6. The method for testing a Flash model in an MCU based on an ATE device according to claim 1, characterized in that: The method further comprises: after completing the test of the Flash model in the MCU to be tested, storing the Flash driver file and the test data file; The specific steps of storing the Flash driver file and the test data file include: Define the naming format of the Flash driver file, the corresponding MCU type and version number, or any number of them; Store the defined Flash driver file and the corresponding test file; And record the change history according to the version of the stored Flash driver file.

7. The method for testing a Flash model in an MCU based on an ATE device according to claim 6, characterized in that: When testing the Flash model in a certain type of MCU, the Flash driver file that is preferentially used is the first driver file; If a Flash driver file is newly acquired, the Flash driver file is compared with the stored Flash driver file; When the newly acquired Flash driver file version is newer than the stored Flash driver file, and the newly acquired Flash driver file meets the preset test conditions, the newly acquired Flash driver file is used as the first driver file, and the test data file is updated accordingly; If the newly acquired Flash driver file does not meet the preset test condition, the next newest Flash driver file is used as the first driver file, and the newly acquired Flash driver file is stored.

8. The method for testing a Flash model in an MCU based on an ATE device according to claim 1, characterized in that: The Flash driver file includes one or more, and the test data file includes one or more; The method further includes: if the Flash driver program file and the test data file are not obtained, testing the Flash based on the Flash driver program file and the corresponding test data file obtained historically.

9. A Flash model testing system in MCU based on ATE equipment, characterized in that: include: An acquisition module is used to acquire Flash driver files and test data files; A parsing module is used to parse the Flash driver file to obtain the Flash driver; A writing module is used to write the Flash driver into the MCU to be tested, and then write the test data file corresponding to the Flash driver into the MCU to be tested; The test module is used to complete the test of the Flash model in the MCU to be tested based on the written Flash driver and test data file.

10. The Flash model testing system in MCU based on ATE equipment according to claim 9, characterized in that: The system also includes: A storage module is used to store the Flash driver file and the test data file after completing the test of the Flash to be tested; The specific steps of storing the Flash driver file and the test data file include: Define the naming format of the Flash driver file, the corresponding MCU type and version number, or any number of them; Store the defined Flash driver file and the corresponding test file; And record the change history according to the version of the stored Flash driver file.

Images