Boot verification method and related equipment for eMMC chips

By building a verification platform and adjusting the delay time between commands, designing multiple test cases to cover more scenarios, the existing eMMC chip Boot boot test methods are solved, and more efficient and comprehensive one-time testing is achieved.

CN119065987BActive Publication Date: 2025-03-11ARTMEM TECHNOLOGY CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411572397.1
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-11-06
Publication Date
2025-03-11
Estimated Expiration
2044-11-06

AI Technical Summary

Technical Problem

The existing eMMC chip Boot boot test method is inefficient and has poor coverage, especially on Android-based platforms. Each reboot test takes 2 minutes and it is difficult to fully cover all possible combinations, resulting in compatibility issues.

Method used

By obtaining the timing verification data of multiple Boot boot platforms, a verification platform is built to simulate the first Boot boot timing of the eMMC chip, and a second Boot boot timing is created by adjusting the delay time between commands, multiple test cases are designed to cover more scenarios, and ultimately improve the comprehensiveness and efficiency of verification.

Benefits of technology

It realizes the completion of tests in a shorter time, improves the testing efficiency and coverage, and ensures the compatibility and stability of eMMC chips under different platforms and conditions.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119065987B_ABST
    Figure CN119065987B_ABST
Patent Text Reader

Abstract

The present application provides a Boot verification method and related equipment for an eMMC chip, including: obtaining timing verification data of multiple Boot platforms; constructing a verification platform based on the multiple timing verification data, so as to simulate the first Boot timing of the eMMC chip on multiple platforms through the verification platform; adjusting the delay time between commands of the multiple first Boot timings to obtain multiple second Boot timings; designing multiple test cases based on the multiple first Boot timings and the multiple second Boot timings, so as to execute the multiple test cases based on a preset automated script to verify the eMMC chip to be verified, wherein the present application can construct a verification platform, simulate multiple Boot timings, and create a new timing combination by adjusting the delay time between commands, so as to design test cases that can cover more scenarios, and ultimately improve the comprehensiveness and efficiency of verification.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of chip testing technology, and in particular to a Boot verification method for an eMMC chip and related equipment. Background Art

[0002] In embedded systems, eMMC (embedded Multi-Media Card) is a common storage solution used in mobile devices such as smartphones and tablets. The Boot function of eMMC is crucial because it ensures that the host can quickly and efficiently read the BootLoader data in the eMMC during startup to load the operating system and other necessary startup programs. The Boot function usually occurs in the Brom stage of the host and relies on the BootLoader data in the Boot1 or Boot2 partition.

[0003] The existing Boot test methods, especially when using Android-based platforms (such as MediaTek, Qualcomm, and Spreadtrum, etc.), have the following problems: First, each restart test takes about 2 minutes, which greatly reduces the test efficiency; second, since the Boot mechanisms of different platforms may be different, it is difficult for the existing test methods to fully cover all possible combinations, which means that the new platform may still have compatibility issues, resulting in low efficiency and poor coverage of the current eMMC chip Boot test. Summary of the invention

[0004] The purpose of the present invention is to solve at least one of the technical problems existing in the prior art, and provide a Boot verification method and related equipment for eMMC chips, which can build a verification platform, simulate multiple Boot timings, and create new timing combinations by adjusting the delay time between commands, so as to design test cases that can cover more scenarios, and ultimately improve the comprehensiveness and efficiency of verification.

[0005] In a first aspect, an embodiment of the present invention provides a Boot verification method for an eMMC chip, comprising: obtaining timing verification data of multiple Boot platforms; constructing a verification platform based on the multiple timing verification data, so as to simulate the first Boot timing of the eMMC chip on multiple platforms through the verification platform; adjusting the delay time between commands for the multiple first Boot timings, so as to obtain multiple second Boot timings; designing multiple test cases based on the multiple first Boot timings and the multiple second Boot timings, so as to execute the multiple test cases based on a preset automation script to verify the eMMC chip to be verified.

[0006] In some embodiments, the obtaining of timing verification data of multiple Boot platforms includes: capturing Boot timing data from multiple Boot platforms, wherein the Boot timing data at least includes a timing relationship between Vcc, Vccq, HwReset, and cmd.

[0007] In some embodiments, the inter-command delay time of the multiple first Boot boot timings is adjusted to obtain multiple second Boot boot timings, including: adjusting the time point of sending the CMD0 command after Vcc is powered on in the multiple first Boot boot timings to simulate the first startup condition and obtain multiple second Boot boot timings.

[0008] In some embodiments, the inter-command delay time adjustment of the multiple first Boot boot timings to obtain multiple second Boot boot timings includes: adjusting the delay time between different CMD0 commands in the multiple first Boot boot timings to simulate the second startup condition to obtain multiple second Boot boot timings.

[0009] In some embodiments, the designing of multiple test cases based on multiple first Boot boot timings and multiple second Boot boot timings includes: obtaining multiple pre-condition configuration information, test scenario information and command sending delay time information based on multiple first Boot boot timings and multiple second Boot boot timings respectively; and designing multiple test cases based on multiple pre-condition configuration information, the test scenario information and the command sending delay time information.

[0010] In some embodiments, executing the multiple test cases based on a preset automation script includes: executing the test cases based on the preset automation script according to the pre-condition configuration information, the test scenario information and the command sending delay time information; in the process of executing the test cases, detecting the correctness of the ACK signal and the Boot data, and outputting the corresponding command sequence and time interval information when an error occurs.

[0011] In some embodiments, the inter-command delay time adjustment of the multiple first Boot boot timings to obtain multiple second Boot boot timings includes: after Vcc in the first Boot boot timing is powered on, keeping the sending time of the F0 command fixed, and obtaining multiple second Boot boot timings by changing the sending time interval between the F0 and FA commands; or, after Vcc in the first Boot boot timing is powered on, keeping the sending time interval between the F0 and FA commands unchanged, and obtaining multiple second Boot boot timings by changing the sending time interval between Vcc power-on and the F0 command.

[0012] In a second aspect, an embodiment of the present invention provides a Boot verification device for an eMMC chip, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the Boot verification method for the eMMC chip as described in the embodiment of the first aspect above.

[0013] In a third aspect, an embodiment of the present invention provides a mobile robot, comprising the Boot verification device for the eMMC chip as described in the embodiment of the second aspect above.

[0014] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the Boot verification method for the eMMC chip as described in the embodiment of the first aspect above.

[0015] The Boot verification method and related devices for eMMC chips provided according to the embodiments of the present invention have at least the following beneficial effects: the embodiments of the present application can collect Boot timing data from different platforms, including but not limited to the timing flow of power-on (Vcc), clock (Vccq), hardware reset (HwReset) and command (cmd); further, using the collected Boot timing data of different platforms, a verification platform is constructed, and the platform can simulate the first Boot timing of the eMMC chip on these platforms. The first Boot timing is the timing during actual operation. On this platform, the present application can control and simulate the timing relationship of signals such as Vcc, Vccq, HwReset, CMD0, etc.; further, on the basis of simulating the Boot timing of the real platform, the delay time between commands, such as the delay between CMD0 and CMD8, is further adjusted. By creating multiple second Boot boot timings, by changing the interval time between commands, a variety of different combination conditions can be generated to cover more unknown combination situations; further, according to the first and second Boot boot timings obtained above, test cases are designed to cover the changing combinations of various power management, initialization sequence, command delay and other factors. The design of the test case should take into account all variables that may affect the success of Boot boot, such as the conversion from power on to off, the specified delay time, etc.; further, using a preset automated test script, execute the designed test case to verify the eMMC chip. The automated script can systematically arrange the test conditions and record the results of each test, including which commands are executed, the time interval between commands and other detailed information. When a problem occurs in the test, more effective information can be output to help analyze the cause of the problem, such as the specific commands issued and their combinations, the time interval between commands, etc. Through the above steps, the scheme of the present invention can not only improve the verification efficiency, but also improve the comprehensiveness of the verification by increasing the coverage of the test case, and provide more debugging information when problems occur.

[0016] Other features and advantages of the present invention will be described in the following description, and partly become apparent from the description, or understood by practicing the present invention. The purpose and other advantages of the present invention can be realized and obtained by the structures particularly pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings are used to provide a further understanding of the technical solution of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the technical solution of the present invention and do not constitute a limitation on the technical solution of the present invention.

[0018] The present invention is further described below in conjunction with the accompanying drawings and embodiments;

[0019] Figure 1 It is a flowchart of a Boot verification method for an eMMC chip provided by an embodiment of the present invention;

[0020] Figure 2 It is another flow chart of the Boot verification method for the eMMC chip provided by an embodiment of the present invention;

[0021] Figure 3 It is another flow chart of the Boot verification method for the eMMC chip provided by an embodiment of the present invention;

[0022] Figure 4 It is another flow chart of the Boot verification method for the eMMC chip provided by an embodiment of the present invention;

[0023] Figure 5 It is another flow chart of the Boot verification method for the eMMC chip provided by an embodiment of the present invention;

[0024] Figure 6 It is another flow chart of the Boot verification method for the eMMC chip provided by an embodiment of the present invention;

[0025] Figure 7 It is another flow chart of the Boot verification method for the eMMC chip provided by an embodiment of the present invention;

[0026] Figure 8 It is a structural diagram of a Boot verification device for an eMMC chip provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0027] This section will describe in detail the specific embodiments of the present invention. The preferred embodiments of the present invention are shown in the accompanying drawings. The purpose of the accompanying drawings is to supplement the description of the text part of the specification with graphics, so that people can intuitively and vividly understand each technical feature and the overall technical solution of the present invention, but it cannot be understood as a limitation on the scope of protection of the present invention.

[0028] In the description of the present invention, "several" means one or more, "more" means more than two, "greater than", "less than", "exceed", etc. are understood to exclude the number itself, "above", "below", "within", etc. are understood to include the number itself, "any one" means one or more, "at least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. If there is a description of the first and the second, it is only used for the purpose of distinguishing the technical features, and cannot be understood as indicating or implying the relative importance or implicitly indicating the number of the indicated technical features or implicitly indicating the order of the indicated technical features.

[0029] It should be noted that the terms such as setting, installing, and connecting in the embodiments of the present invention should be understood in a broad sense, and those skilled in the art can reasonably determine the specific meanings of the above terms in the embodiments of the present invention in combination with the specific content of the technical solution. For example, the term "connection" can be a mechanical connection, an electrical connection, or mutual communication; it can be directly connected or indirectly connected through an intermediate medium.

[0030] It should be noted that the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0031] In embedded systems, eMMC (embedded Multi-Media Card) is a common storage solution used in mobile devices such as smartphones and tablets. The Boot function of eMMC is crucial because it ensures that the host can quickly and efficiently read the BootLoader data in the eMMC during startup to load the operating system and other necessary startup programs. The Boot function usually occurs in the Brom stage of the host and relies on the BootLoader data in the Boot1 or Boot2 partition. The existing Boot test methods, especially when using Android-based platforms (such as MediaTek, Qualcomm, and Spreadtrum, etc.), have the following problems: First, each restart test takes about 2 minutes, which greatly reduces the test efficiency. Second, since the Boot mechanisms of different platforms may be different, it is difficult for the existing test methods to fully cover all possible combinations, which means that new platforms may still have compatibility issues, resulting in low efficiency and poor coverage of the current eMMC chip Boot test.

[0032] The embodiments of the present invention are further described below in conjunction with the accompanying drawings.

[0033] refer to Figure 1 , Figure 1 It is a flow chart of a Boot verification method for an eMMC chip provided by an embodiment of the present invention; in a first aspect, an embodiment of the present invention provides a Boot verification method for an eMMC chip, including but not limited to the following steps:

[0034] Step S110, obtaining timing verification data of multiple Boot platforms;

[0035] Step S120, constructing a verification platform according to the plurality of timing verification data, so as to simulate the first Boot timing of the eMMC chip on the plurality of platforms through the verification platform;

[0036] Step S130, adjusting the delay time between commands of the plurality of first Boot timings to obtain a plurality of second Boot timings;

[0037] Step S140, designing a plurality of test cases according to the plurality of first Boot boot sequences and the plurality of second Boot boot sequences, and executing the plurality of test cases based on a preset automation script to verify the eMMC chip to be verified.

[0038] Among them, the Boot platform refers to the hardware platform that supports eMMC startup, such as smartphone motherboards, development boards, etc., which have specific hardware configurations and startup logic; the timing verification data refers to the time point data of changes in various key signals (such as Vcc, Vccq, HwReset, etc.) during the startup process. These data reflect the state changes of various signals of the eMMC chip during the startup process.

[0039] In some embodiments, the verification platform is an environment used to simulate the eMMC startup process in this application, which can be a hardware emulator or a software simulation tool, used to reproduce the startup behavior of the eMMC chip on different platforms. The first Boot boot timing refers to the actual timing process when the eMMC chip starts on a specific hardware platform, including the time point and duration of the signal change. The delay time between commands refers to the time interval between the execution of different commands during the eMMC startup process, for example, after sending CMD0, wait for a period of time before sending CMD8. The second Boot boot timing refers to a new timing combination obtained by adjusting the first Boot boot timing, such as adjusting the delay time between commands. These combinations are used to test whether the eMMC chip can start correctly under different conditions. The test case is a series of operation sequences designed to verify the startup reliability of the eMMC chip, and each test case represents a specific set of startup conditions. The preset automation script is a pre-written program code for automatically executing test cases and recording results, simplifying the process of manual intervention, and improving test efficiency. The eMMC chip to be verified refers to the target eMMC chip that needs to be started and verified by the above method.

[0040] Among them, the embodiments of the present application can collect Boot boot timing data from different platforms, which include but are not limited to the timing flow of power-on (Vcc), clock (Vccq), hardware reset (HwReset) and command (cmd); further, use the collected Boot boot timing data of different platforms to build a verification platform, which can simulate the first Boot boot timing of the eMMC chip on these platforms. The first Boot boot timing is the timing of the actual working time. On this platform, the present application can control and simulate the timing relationship of signals such as Vcc, Vccq, HwReset, CMD0, etc.; further, on the basis of simulating the Boot boot timing of the real platform, further adjust the delay time between commands, such as the delay between CMD0 and CMD8, to create multiple second Boot boot timings, by changing the command The interval time between the first and second Boot boot sequences can generate a variety of different combination conditions to cover more unknown combinations; further, according to the first and second Boot boot timings obtained above, test cases are designed to cover the combination of various power management, initialization sequence, command delay and other factors. The design of the test case should take into account all variables that may affect the success of the Boot boot, such as the conversion from power on to off, the specified delay time, etc.; further, using the preset automated test script, the designed test case is executed to verify the eMMC chip. The automated script can systematically arrange the test conditions and record the results of each test, including which commands are executed, the time interval between commands and other detailed information. When a problem occurs in the test, more effective information can be output to help analyze the cause of the problem, such as the specific commands issued and their combinations, the time interval between commands, etc. Through the above steps, the scheme of the present invention can not only improve the verification efficiency, but also improve the comprehensiveness of the verification by increasing the coverage of the test cases, and provide more debugging information when problems occur.

[0041] It can be understood that on the verification platform, a new timing combination, the so-called second Boot timing, is generated by changing the delay time between commands. This step is to simulate different startup conditions in order to more comprehensively test the performance of the eMMC chip. According to the above-mentioned first Boot timing and second Boot timing, multiple test cases are designed, and automated scripts are written to execute these test cases, thereby comprehensively and effectively verifying the functions of the eMMC chip to be tested.

[0042] In some embodiments, the step of obtaining timing verification data of multiple Boot platforms also includes: collecting additional environmental parameters from multiple Boot platforms, such as data on the impact of environmental factors such as temperature and humidity on the startup timing of the eMMC chip. These environmental parameters can help more accurately simulate the startup performance of the eMMC chip under different environmental conditions, thereby improving the comprehensiveness and accuracy of the test. For example, the key signal change time point data when the eMMC chip is started in low temperature (-20°C) and high temperature (85°C) environments can be collected, and by comparing the startup timing differences under different temperature conditions, the stability of the eMMC chip under extreme temperature conditions can be evaluated.

[0043] In some embodiments, the step of adjusting the delay time between commands for multiple first Boot boot sequences further includes: while adjusting the delay time between commands, introducing random noise or jitter to simulate interference factors that may exist in the actual environment. For example, when adjusting the delay time between CMD0 and CMD8, ±10% random noise may be added, which can more realistically simulate the influence of environmental factors such as electromagnetic interference that the eMMC chip may encounter in actual applications, thereby improving the reliability and practicality of the test results.

[0044] In some embodiments, the step of designing multiple test cases according to multiple first Boot boot timings and multiple second Boot boot timings also includes: designing test cases including an exception handling mechanism to verify the recovery capability of the eMMC chip in the face of abnormal situations. For example, a test case can be designed to intentionally introduce an erroneous response after certain key commands (such as CMD0) are sent to observe whether the eMMC chip can correctly handle these abnormal situations and resume normal operation. This can not only test the basic startup function of the eMMC chip, but also evaluate its robustness and fault tolerance in abnormal situations.

[0045] refer to Figure 2 , Figure 2 1 is another flow chart of a Boot verification method for an eMMC chip provided by an embodiment of the present invention; in some embodiments, obtaining timing verification data of multiple Boot platforms includes but is not limited to the following steps:

[0046] Step S210, capturing Boot timing data from multiple Boot platforms, where the Boot timing data at least includes the timing relationship between Vcc, Vccq, HwReset, and cmd.

[0047] In some embodiments, the present application can capture Boot timing data from different Boot platforms (such as MTK, Qualcomm, Spreadtrum and other mobile phone platforms), and these data mainly include: Vcc (power supply voltage): a signal indicating the power supply of the eMMC chip. Vccq (power clock): refers to the power supply that provides the clock signal for the eMMC. HwReset (hardware reset): a signal used to reset the eMMC chip. Cmd (command): refers to the control command sent to the eMMC, and then a dedicated code script can be designed according to the timing to shorten the reboot from 2 minutes to 20 seconds.

[0048] It is understandable that by obtaining Boot timing data from multiple Boot platforms (such as MTK, Qualcomm, Spreadtrum, etc.), it can ensure that the verification method covers as many real application scenarios as possible, thereby improving the comprehensiveness and effectiveness of the test. These data provide a solid foundation for subsequent verification, making the timing adjustment and test case design in subsequent steps more targeted and scientific.

[0049] refer to Figure 3 , Figure 3 1 is another flow chart of a Boot verification method for an eMMC chip provided by an embodiment of the present invention; in some embodiments, a plurality of first Boot timings are subjected to inter-command delay adjustment to obtain a plurality of second Boot timings, including but not limited to the following steps:

[0050] Step S310, adjusting the time point of sending the CMD0 command after Vcc is powered on in the plurality of first Boot timings to simulate the first startup condition and obtain a plurality of second Boot timings.

[0051] In some embodiments, the present application can simulate different startup conditions by adjusting the time point of sending the CMD0 command after Vcc is powered on, thereby obtaining multiple second Boot boot timings. Specifically: by selecting Vcc power-on as the starting time point, sending the CMD0 command at different time points after Vcc is powered on, for example, sending it after 50 microseconds, and immediately (such as 5 microseconds) sending another variant command of CMD0 (such as CMD0+0xFFFFFFFA) after sending the CMD0 command, by changing the time interval between the two commands, different combination conditions can be created, for example, ranging from 5 microseconds to 1000 milliseconds.

[0052] It is understandable that by adjusting the time point of sending the CMD0 command after Vcc is powered on, a variety of different startup conditions can be simulated. For example, changing the time interval between the CMD0 command and the variant command of CMD0 (such as CMD0+0xFFFFFFFA) from a few microseconds to a few milliseconds can help discover the behavioral differences of the eMMC chip under different conditions, so that the present application can effectively identify the behavior of the eMMC under different startup conditions, thereby ensuring that the eMMC chip can work stably under various conditions.

[0053] refer to Figure 4 , Figure 4 1 is another flow chart of a Boot verification method for an eMMC chip provided by an embodiment of the present invention; in some embodiments, a plurality of first Boot timings are subjected to inter-command delay adjustment to obtain a plurality of second Boot timings, including but not limited to the following steps:

[0054] Step S410, adjusting the delay time between different CMD0 commands in a plurality of first Boot timing sequences to simulate a second startup condition and obtain a plurality of second Boot timing sequences.

[0055] In some embodiments, this step simulates another startup condition by adjusting the delay time between different CMD0 commands, thereby obtaining multiple second Boot timings. The specific implementation method is: after Vcc is powered on, the sending time of the first CMD0 command is fixed, and the delay time between the first CMD0 command and the second CMD0 command is adjusted to simulate different startup conditions. For example, the first CMD0 command is kept sent 50 microseconds after Vcc is powered on, but the delay time of the second CMD0 command relative to the first CMD0 command is changed from a few microseconds to a few milliseconds.

[0056] It can be understood that through the above steps, in addition to adjusting the time point of sending CMD0 after Vcc is powered on, the present application can also further expand the scope of the test by changing the delay time between different CMD0 commands, thereby ensuring the performance of eMMC under more combination conditions and making the verification process more refined.

[0057] In some embodiments, the present application can simulate multiple startup conditions and design multiple test cases based on these conditions, which are then executed based on preset automation scripts to verify the startup behavior of the eMMC chip under different conditions. This method can not only improve test efficiency, but also cover a wider range of startup combinations, help discover potential problems and provide detailed debugging information.

[0058] refer to Figure 5 , Figure 5It is another flow chart of the Boot verification method for the eMMC chip provided by an embodiment of the present invention; in some embodiments, multiple test cases are designed according to multiple first Boot timings and multiple second Boot timings, including but not limited to the following steps:

[0059] Step S510, obtaining a plurality of precondition configuration information, test scenario information and command sending delay time information according to a plurality of first Boot boot timings and a plurality of second Boot boot timings respectively;

[0060] Step S520, designing multiple test cases according to multiple precondition configuration information, test scenario information and command sending delay time information.

[0061] In some embodiments, multiple pre-condition configuration information, test scenario information and command sending delay time information are obtained according to multiple first Boot boot timings and multiple second Boot boot timings respectively. In the above steps, the present application can extract multiple pre-condition configuration information, test scenario information and command sending delay time information based on the Boot boot timing data captured from different platforms (including the timing relationship between Vcc, Vccq, HwReset, and cmd), and multiple second Boot boot timings obtained by adjusting the delay time between commands.

[0062] Among them, the precondition configuration information refers to the environmental parameters that need to be set before executing the test case, such as the power status, the status of the reset signal, etc. The test scenario information describes the specific steps that need to be followed when executing the test, including which commands to send and the order in which the commands are sent. The command sending delay time information refers to the time interval between different commands during the test process. These intervals may be fixed or may vary within a certain range. Specifically, the above configuration steps can be implemented by determining the design function Func_boot_verify(Pre_condition, Case, T1, T2, T3), where Pre_condition represents the precondition configuration information, Case represents different test scenario information, and T1, T2, and T3 represent different command sending delay times.

[0063] In some embodiments, after obtaining the above information, the present application can integrate the information to design multiple test cases, each of which is a specific test scenario, including a series of steps from power management to sending initialization commands, as well as the time interval between each step.

[0064] refer to Figure 6 , Figure 61 is another flow chart of the Boot verification method for the eMMC chip provided by an embodiment of the present invention; in some embodiments, multiple test cases are executed based on a preset automation script, including but not limited to the following steps:

[0065] Step S610, based on a preset automation script, executing the test case according to the precondition configuration information, the test scenario information and the command sending delay time information;

[0066] Step S620, during the execution of the test case, the correctness of the ACK signal and the Boot data is detected, and when an error occurs, the corresponding command sequence and time interval information are output.

[0067] In some embodiments, when executing a test, the present application may use a preset automation script, set preconditions according to the designed test case, and execute the test according to the predetermined test scenario information and command sending delay time information. The automation script can automatically complete various tasks in the test process, including setting the power state, sending initialization commands, recording command execution time and results, etc.

[0068] It is conceivable that during the test, the application can monitor the ACK signal (confirmation signal) and the correctness of the Boot data. If a problem occurs during the test, the system will record the command sequence (i.e., which commands were sent) and the time interval between these commands when the problem occurred, and output this information for debugging. This information is very important for debugging because it can help engineers quickly locate the problem and take measures to solve it.

[0069] Through the above steps, it can be ensured that the startup behavior of the eMMC chip can be fully tested under different Boot timing conditions, and detailed debugging information can be provided when problems occur, thereby improving the comprehensiveness and efficiency of verification.

[0070] refer to Figure 7 , Figure 7 1 is another flow chart of a Boot verification method for an eMMC chip provided by an embodiment of the present invention; in some embodiments, a plurality of first Boot timings are subjected to inter-command delay adjustment to obtain a plurality of second Boot timings, including but not limited to the following steps:

[0071] Step S710, after Vcc in the first Boot sequence is powered on, the sending time of the F0 command is kept fixed, and a plurality of second Boot sequences are obtained by changing the sending time interval between the F0 and FA commands;

[0072] Step S720, or, after Vcc is powered on in the first Boot sequence, the sending time interval between F0 and FA commands is kept unchanged, and multiple second Boot sequences are obtained by changing the sending time interval between Vcc power-on and F0 command.

[0073] In some embodiments, the delay time between commands is adjusted for multiple first Boot boot sequences to obtain multiple second Boot boot sequences. After Vcc in the first Boot boot sequence is powered on, the sending time of the F0 command is kept fixed. By changing the sending time interval between the F0 and FA commands, multiple second Boot boot sequences are obtained. New startup conditions are constructed by changing the time interval between the F0 command and the FA command. The specific operation is as follows: after Vcc (power supply voltage) is powered on, a fixed time is set to send the CMD0 (F0 is the abbreviation of CMD0 0xF0F0F0F0) command. After sending CMD0, immediately (for example, 5 microseconds later) send the CMD0 0xFFFFFFFA (FA is the abbreviation of CMD0 0xFFFFFFFA) command. By changing this time interval (ranging from 5 microseconds to 1000 milliseconds), different startup condition combinations can be created. These adjusted time interval combinations form multiple new startup timings, namely, second Boot boot timings, for subsequent testing.

[0074] In some embodiments, after Vcc is powered on in the first Boot boot sequence, the sending time interval between F0 and FA commands is kept unchanged, and multiple second Boot boot sequences are obtained by changing the sending time interval between Vcc power-on and F0 commands, so as to construct new startup conditions by changing the time interval between Vcc power-on and CMD0 (F0) command. The specific operation is as follows: keep the time interval between CMD0 command (F0) and CMD0 0xFFFFFFFA (FA) command unchanged, change the time interval between Vcc power-on and F0 command, and after Vcc is powered on, change the time point when CMD0 command is sent. For example, CMD0 is sent 50 microseconds after Vcc is powered on, but this time can be changed to other values, such as 100 microseconds, 500 microseconds, etc. These adjusted time interval combinations also form multiple new startup timings, namely the second Boot boot timings, for subsequent testing.

[0075] Through the above steps, multiple different startup conditions can be constructed, and then multiple second Boot timings can be obtained. These new timing combinations can help verify the performance of the eMMC chip under different startup conditions, thereby improving the comprehensiveness and efficiency of verification.

[0076] In summary, in the process of obtaining the timing verification data of multiple Boot platforms, this application captures Boot timing data from multiple Boot platforms (such as MTK, Qualcomm, Spreadtrum and other mobile phone platforms), which mainly include the timing relationship between Vcc (power supply voltage), Vccq (power supply clock), HwReset (hardware reset) and cmd (command). By obtaining Boot timing data from different platforms, it can be ensured that the verification method covers as many real application scenarios as possible, thereby improving the comprehensiveness and effectiveness of the test.

[0077] In the process of building the verification platform, a verification platform is built based on the multiple timing verification data obtained. The platform can simulate the first Boot boot timing of the eMMC chip on multiple platforms. The first Boot boot timing is the timing during actual operation, including the time point and duration of signal changes. On this platform, the startup behavior of the eMMC chip on different platforms can be reproduced by controlling and simulating the timing relationship of signals such as Vcc, Vccq, HwReset, and CMD0.

[0078] In the process of adjusting the delay time between commands, the delay time between commands is further adjusted on the basis of simulating the Boot timing of the real platform, such as the delay between CMD0 and CMD8, to create multiple second Boot timings. By changing the interval time between commands, a variety of different combination conditions can be generated to cover more unknown combination situations. Specifically, the delay time between commands can be adjusted in the following two ways:

[0079] By adjusting the time point of sending the CMD0 command after Vcc is powered on, the CMD0 command can be sent at different time points after Vcc is powered on, such as 50 microseconds later, and then immediately (such as 5 microseconds later) another variant command of CMD0 (such as CMD0+0xFFFFFFFA). By changing the time interval between these two commands, different combination conditions can be created, such as ranging from 5 microseconds to 1000 milliseconds.

[0080] By adjusting the delay time between different CMD0 commands, the sending time of the first CMD0 command is fixed after Vcc is powered on, and the delay time between the first CMD0 command and the second CMD0 command is adjusted to simulate different startup conditions. For example, the first CMD0 command is kept sent 50 microseconds after Vcc is powered on, but the delay time of the second CMD0 command relative to the first CMD0 command is changed from a few microseconds to a few milliseconds.

[0081] In the process of designing test cases, multiple test cases are designed according to multiple first Boot boot sequences and multiple second Boot boot sequences. Each test case is a specific test scenario, which includes a series of steps from power management to sending initialization commands, as well as the time interval between each step. The design of test cases should take into account all variables that may affect the success of Boot boot, such as the transition from power on to power off, the specified delay time, etc.

[0082] According to the first Boot sequence and the second Boot sequence, multiple precondition configuration information, test scenario information and command sending delay time information are extracted. Precondition configuration information refers to the environmental parameters that need to be set before executing the test case, such as power status, reset signal status, etc. Test scenario information describes the specific steps that need to be followed when executing the test, including which commands to send and the order in which the commands are sent. Command sending delay time information refers to the time interval between different commands during the test process. The above information is integrated to design multiple test cases, each of which covers a specific set of startup conditions.

[0083] In the process of executing the test cases, the preset automated test scripts are used to execute the designed test cases to verify the eMMC chip. The automated script can systematically arrange the test conditions and record the results of each test, including which commands are executed, the time interval between commands and other detailed information. During the test, the ACK signal (confirmation signal) and the correctness of the Boot data are monitored. If there is a problem during the test, the system will record the command sequence (that is, which commands were sent) and the time interval between these commands when the problem occurred, and output this information for debugging. This information is very important for debugging because it can help engineers quickly locate the problem and take measures to solve it.

[0084] Through the above steps, this application can not only improve the verification efficiency, but also improve the comprehensiveness of the verification by increasing the coverage of test cases and providing more debugging information when problems occur, thereby ensuring the stability and reliability of the eMMC chip under various startup conditions.

[0085] Second, refer to Figure 8 , Figure 8 It is a structural diagram of a Boot verification device 800 for an eMMC chip provided in an embodiment of the present invention, wherein the operation control device 800 includes: a memory 810, a processor 820, and a computer program stored in the memory 810 and executable on the processor 820. When the processor 820 executes the computer program, the Boot verification method for the eMMC chip in the above embodiment is implemented.

[0086] The memory 810 is a non-transitory computer-readable storage medium that can be used to store non-transitory software programs and non-transitory computer executable programs, such as the Boot verification method for the eMMC chip in the above embodiment of the present invention. The processor 820 implements the Boot verification method for the eMMC chip in the above embodiment of the present invention by running the non-transitory software programs and instructions stored in the memory 810.

[0087] The memory 810 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required by at least one function; the data storage area may store data required to execute the Boot boot verification method for the eMMC chip in the above embodiment, etc. In addition, the memory 810 may include a high-speed random access memory 810, and may also include a non-transitory memory 810, such as at least one disk storage device, a flash memory device, or other non-transitory solid-state storage device. It should be noted that the memory 810 may optionally include a memory 810 remotely arranged relative to the processor 820, and these remote memories 810 may be connected to the terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0088] The non-transient software program and instructions required to implement the Boot verification method for the eMMC chip in the above embodiment are stored in the memory. When executed by one or more processors, the Boot verification method for the eMMC chip in the above embodiment is executed. For example, the above embodiment is executed. Figure 1 Steps S110 to S140 of the method, Figure 2 In the method step S210, Figure 3 Step S310 of the method, Figure 4 In the method step S410, Figure 5 Steps S510 to S520 of the method, Figure 6 Steps S610 to S620 of the method, Figure 7 Method steps S710 to S720.

[0089] In a third aspect, the present invention provides a mobile robot, comprising a Boot verification device for an eMMC chip as in the second aspect.

[0090] In a fourth aspect, the present invention further provides a computer-readable storage medium, the computer-readable storage medium storing computer-executable instructions, the computer-executable instructions being used to enable a computer to execute the Boot verification method for an eMMC chip in the embodiment of the first aspect above, for example, to execute the above embodiment. Figure 1Steps S110 to S140 of the method, Figure 2 In the method step S210, Figure 3 Step S310 of the method, Figure 4 In the method step S410, Figure 5 Steps S510 to S520 of the method, Figure 6 Steps S610 to S620 of the method, Figure 7 Method steps S710 to S720.

[0091] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to output requirements to achieve the purpose of the present embodiment.

[0092] It will be appreciated by those skilled in the art that all or some of the steps and systems in the disclosed methods above may be implemented as software, firmware, hardware and appropriate combinations thereof. Some physical components or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium or a non-transitory medium and a communication medium or a temporary medium. As known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disk DVD or other optical disk storage, magnetic cassettes, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that may be used to store desired information and may be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0093] The embodiments of the present invention are described in detail above with reference to the accompanying drawings, but the present invention is not limited to the above embodiments, and various changes can be made within the knowledge scope of ordinary technicians in the technical field without departing from the purpose of the present invention.

Claims

1. A Boot verification method for an eMMC chip, characterized in that: include: Obtain timing verification data for multiple Boot platforms; Building a verification platform according to the plurality of timing verification data, so as to simulate the first Boot timing of the eMMC chip on the plurality of platforms through the verification platform; Adjusting the delay time between commands of the plurality of the first Boot timings to obtain a plurality of second Boot timings; Designing a plurality of test cases according to the plurality of the first Boot boot timings and the plurality of the second Boot boot timings, and executing the plurality of test cases to verify the eMMC chip to be verified based on a preset automation script; The step of adjusting the delay time between commands of the plurality of the first Boot boot timings to obtain the plurality of second Boot boot timings includes: Adjusting the time point of sending the CMD0 command after Vcc is powered on in the first Boot timings to simulate the first startup condition and obtain the second Boot timings; Adjust the delay time between CMD0 and CMD8 in the plurality of first Boot timings to simulate the second startup condition, and add ±10% random noise when adjusting the delay time between CMD0 and CMD8; The step of designing multiple test cases according to the multiple first Boot boot timings and the multiple second Boot boot timings includes: Obtaining a plurality of precondition configuration information, test scenario information and command sending delay time information according to a plurality of the first Boot boot timings and a plurality of the second Boot boot timings respectively; Designing multiple test cases according to the multiple precondition configuration information, the test scenario information and the command sending delay time information; The executing of the plurality of test cases based on a preset automation script includes: Based on a preset automation script, the test case is executed according to the precondition configuration information, the test scenario information and the command sending delay time information; During the execution of the test case, the correctness of the ACK signal and the Boot data is detected, and when an error occurs, the corresponding command sequence and time interval information are output; The step of adjusting the delay time between commands of the plurality of the first Boot boot timings to obtain a plurality of second Boot boot timings includes: After Vcc in the first Boot sequence is powered on, the sending time of the F0 command is kept fixed, and a plurality of second Boot sequences are obtained by changing the sending time interval between the F0 and FA commands; Alternatively, after Vcc is powered on in the first Boot sequence, the time interval between sending the F0 and FA commands is kept unchanged, and a plurality of second Boot sequences are obtained by changing the time interval between Vcc powering on and sending the F0 command.

2. The Boot verification method for eMMC chip according to claim 1, characterized in that: The step of obtaining timing verification data of multiple Boot platforms includes: Capture Boot timing data from multiple Boot platforms, where the Boot timing data at least includes a timing relationship among Vcc, Vccq, HwReset, and cmd.

3. A Boot verification device for an eMMC chip, characterized in that: The invention comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the Boot verification method for the eMMC chip as described in any one of claims 1 to 2.

4. An electronic device, characterized in that: It includes the Boot verification device for the eMMC chip as described in claim 3.

5. A computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to execute the Boot verification method for an eMMC chip as described in any one of claims 1 to 2.

Citation Information

Patent Citations

  • Segmented verification method, device and equipment for chip bootstrap program and readable medium

    CN115544523A

  • Chip verification method and system

    CN118095163A