Chip testing method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a chip testing method and device, electronic equipment and a storage medium, and belongs to the technical field of equipment testing. The method comprises the steps that to-be-processed data are processed according to a preset error injection strategy, test data are obtained, and the error injection strategy is used for processing the to-be-processed data into distortion data and / or data not meeting a target protocol; sending the test data to a chip to be tested so as to indicate the chip to be tested to perform cyclic redundancy check on the test data; and receiving feedback data sent by the chip, and obtaining a test result based on the feedback data. The problem of low controllability of the CRC error simulation test in the prior art can be solved.

Description

Technical Field

[0001] This application relates to the field of equipment testing technology, and in particular to a chip testing method, apparatus, electronic device and storage medium. Background Technology

[0002] Embedded Multi Media Cards (eMMCs), as an integrated storage solution, are widely used in various electronic devices such as smartphones, tablets, and automotive electronics. In the research, verification, and reliability testing of eMMC devices, SD cards, TF cards, and other chips, Cyclic Redundancy Check (CRC) error simulation is one of the core testing scenarios. Its purpose is to verify the error identification and recovery mechanisms of the device firmware, drivers, and hardware, ensuring that they can effectively cope with potential problems such as signal interference and timing deviations in practical applications, thereby improving the robustness and compatibility of the product.

[0003] However, existing methods for simulating CRC errors mainly rely on external hardware interference at the physical layer, such as creating signal disturbances by shorting the eMMC's data line (DAT), command line (CMD), or clock line (CLK). This method is highly random and cannot reliably trigger errors within a specified command or data transmission cycle, leading to unpredictable test results. Summary of the Invention

[0004] The main objective of this application is to provide a chip testing method, apparatus, electronic device, and storage medium, aiming to solve the problem of low controllability in CRC error simulation testing in the prior art.

[0005] To achieve the above objectives, a first aspect of this application provides a chip testing method, the method comprising: The data to be processed is processed according to a preset error injection strategy to obtain test data. The error injection strategy is used to process the data to be processed into distorted data and / or data that does not meet the target protocol. The test data is sent to the chip under test to instruct the chip under test to perform cyclic redundancy check on the test data. The system receives feedback data sent by the chip and obtains test results based on the feedback data.

[0006] In some embodiments, the error injection strategy includes at least one of a first error injection strategy and a second error injection strategy; The first error injection strategy includes dynamically adjusting the target drive strength to process the data to be processed into distorted data; The second error injection strategy includes processing the data to be processed into data that does not meet the target protocol.

[0007] In some embodiments, the data to be processed is processed according to a preset error injection strategy to obtain test data, including: Upon receiving the first instruction, the data to be processed is processed according to the first error injection strategy to obtain the test data; The first instruction is used to indicate whether a cyclic redundancy check error is triggered during data transmission or when a target command is sent.

[0008] In some embodiments, a general-purpose input / output pin on the electronic device testing the chip is shorted to a target communication line of the chip; The data to be processed is processed according to the first error injection strategy to obtain the test data, including: Before sending the data to be processed to the chip through the target communication line, the general-purpose input / output pin is configured with a first drive strength; After sending the data to be processed to the chip through the target communication line and before the transmission is completed, a preset command is written to the configuration register of the electronic device to increase the drive strength of the general-purpose input / output pin from the first drive strength to the second drive strength, thereby obtaining the test data.

[0009] In some embodiments, after increasing the drive strength of the general-purpose input / output pin from the first drive strength to the second drive strength, the method further includes: After the data to be processed is sent to the chip through the target communication line, the drive strength of the general-purpose input / output pin is restored from the second drive strength to the first drive strength to avoid affecting subsequent normal communication.

[0010] In some embodiments, the data to be processed is processed according to a preset error injection strategy to obtain test data, including: Upon receiving the second instruction, the data to be processed is processed according to the second error injection strategy to obtain the test data; The second instruction is used to instruct a cyclic redundancy check error to be triggered during data transmission; The data to be processed is processed according to the second error injection strategy, including: The data packets to be processed are modified to contain M bytes of valid data and N bytes of invalid data, wherein the sum of M and N satisfies the byte size required by the target protocol.

[0011] In some embodiments, a continuous clock signal is provided to the chip during testing.

[0012] To achieve the above objectives, a second aspect of this application provides a chip testing apparatus, the apparatus comprising: The processing module is used to process the data to be processed according to a preset error injection strategy to obtain test data. The error injection strategy is used to process the data to be processed into distorted data and / or data that does not meet the target protocol. The sending module is used to send the test data to the chip under test, so as to instruct the chip under test to perform cyclic redundancy check on the test data; The receiving module is used to receive feedback data sent by the chip and obtain test results based on the feedback data.

[0013] To achieve the above objectives, a third aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect.

[0014] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.

[0015] The chip testing method, apparatus, electronic device, and storage medium proposed in this application process the data to be processed to generate test data through a preset error injection strategy. After sending the test data to the embedded multimedia card under test, the method receives the test result obtained by the card performing a cyclic redundancy check (CRC) on the test data. If the result indicates that there is a CRC check error, the embedded multimedia card is deemed to have passed the test. Its technical advantage lies in its ability to specifically verify the effectiveness of the CRC check function of the embedded multimedia card, ensuring that the device can accurately identify erroneous data encountered in actual data transmission. At the same time, the test logic is simple and highly targeted, effectively improving test efficiency and the reliability of test results. Attached Figure Description

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

[0017] Figure 1 This is a schematic flowchart of the chip testing method provided in the embodiments of this application; Figure 2 This is a schematic diagram illustrating the shorting of the host's GPIO and the eMMC's CMD / DATA according to an embodiment of this application; Figure 3 This is a schematic diagram of the on-site waveform of CRC error generated by CMD in Embodiment 2 provided in this application; Figure 4 This is a schematic diagram of the on-site waveform of DATA generating CRC error in Embodiment 1 provided in this application; Figure 5 This is a schematic diagram of the chip testing device provided in the embodiments of this application; Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

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

[0019] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0021] eMMC devices are widely used in mobile terminals, embedded systems, and data center storage. Their communication reliability and error recovery capabilities are crucial for ensuring data integrity and system stability. In the research, verification, and reliability testing of eMMC devices, SD cards, TF cards, and other chips, simulating CRC errors is a core test scenario for verifying the device's firmware, drivers, and hardware error handling mechanisms. By artificially injecting CRC errors, the device's response behavior under abnormal conditions can be systematically evaluated, ensuring that it can effectively cope with potential problems such as signal interference and timing deviations in practical applications, thereby improving the product's robustness and compatibility.

[0022] However, existing methods for simulating CRC errors primarily rely on external hardware interference at the physical layer, such as creating signal disturbances by shorting the eMMC's data line (DAT), command line (CMD), or clock line (CLK). These methods have significant drawbacks: First, their success is highly random, failing to reliably trigger errors within a specified command or data transmission cycle, leading to uncontrollable test results. Second, because the timing and intensity of interference are difficult to control precisely, test conditions cannot be reproduced, resulting in unreliable verification results. Furthermore, aggressive hardware interference can easily trigger system-level risks such as bus deadlock and device initialization failures, and may even cause hardware damage. Finally, these methods typically require dedicated hardware tools (such as signal generators and flying leads), increasing testing complexity and cost. Therefore, the industry has long lacked a purely software-implemented, highly controllable, and precisely timed CRC error injection scheme, severely restricting the improvement of chip testing efficiency and verification depth.

[0023] Based on this, the embodiments of this application provide a chip testing method, apparatus, electronic device and storage medium, aiming to develop a CRC error injection method that is purely software-implemented, highly controllable and allows for precise specification of trigger timing, which is of great significance for improving the testing efficiency and reliability of storage chips.

[0024] The chip testing method, apparatus, electronic device, and storage medium provided in this application are specifically described through the following embodiments. First, the chip testing method in this application is described.

[0025] The chip testing method provided in this application relates to the field of device testing technology. The chip testing method provided in this application can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application implementing the chip testing method, but is not limited to the above forms.

[0026] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0027] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the proper functioning of these embodiments acquired.

[0028] Figure 1 This is a schematic flowchart of a chip testing method provided in an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S100 to S300.

[0029] Step S100: The data to be processed is processed according to a preset error injection strategy to obtain test data. The error injection strategy is used to process the data to be processed into distorted data and / or data that does not meet the target protocol.

[0030] In this embodiment, the chip may include an eMMC chip, an SD card, a TF card, etc. The electronic device (as the test host) first generates or acquires a normal piece of data to be sent to the eMMC or SD / TF card. This data can be a specific command (such as CMD, ACMD) or any data type commonly used during the normal operation of the eMMC or SD / TF card (such as text data, binary data, etc.). The data is processed according to a preset error injection strategy to obtain test data; wherein, the preset error injection strategy refers to rules set to trigger CRC check errors, ensuring that the CRC check will inevitably fail.

[0031] Specifically, the preset error injection strategies mainly include, but are not limited to, the following two implementation methods: Implementation Method 1: CRC Error Injection Strategy for Data (DATA). This strategy leverages the eMMC protocol's requirement that data transmission must be a multiple of 512 bytes. The configuration process is as follows: Software instructions control the host's DMA (Direct Memory Access) controller, configuring a data transmission length less than 512 bytes (e.g., 200 bytes) while maintaining a continuously active clock (CLK) signal. With this configuration, the eMMC must continuously sample the data line as long as the clock signal is active. After receiving 200 bytes of valid data, it continues sampling the subsequent 312 bytes because the clock is still active. However, the DMA has stopped operating, and the data line level remains in a fixed state (e.g., high or low). Therefore, the eMMC device actually receives a corrupted 512-byte data block consisting of "200 bytes of valid data + 312 bytes of invalid static data." The eMMC hardware performs a CRC check on this supposedly complete 512-byte data block. The host's CRC is incorrect because it is all 0s or all 1s. However, the CRC calculated by eMMC is correct. eMMC calculates a correct CRC value based on 200 valid data bytes + 312 invalid data bytes. This CRC value is then compared with all 0s / all 1s. The CRC check will fail 100%, and the eMMC device will then report a CRC error.

[0032] Implementation Method 2: CRC Error Injection Strategy Targeting Commands (CMD) or Data (DATA). This strategy dynamically adjusts the drive strength of a GPIO pin shorted to the eMMC signal line to precisely interfere with the signal waveform within a nanosecond time window. The configuration process includes: pre-setting a configurable drive strength GPIO pin on the host side to a high-level output and shorting it to the eMMC's CMD signal line (or DATA signal line, such as DAT0) using a jumper wire. Within a very short time (nanosecond window) when the host controller sends a specific target eMMC command (e.g., CMD18), the drive strength of this GPIO pin is instantly increased (e.g., from 2mA to 8mA or 12mA) by directly writing to the host's hardware register via software. This operation is directly controlled by the underlying registers, ensuring a nanosecond-level response speed and completing the configuration within the target command transmission cycle. With the above configuration, during the transmission of the target command, the sudden change in drive strength will generate a strong "pulling" effect, causing distortion of the CMD (or DATA) signal waveform (such as overshoot, ringing, or level jumps). This interfered and distorted signal constitutes the test data in this step.

[0033] Step S200: The test data is sent to the chip under test to instruct the chip under test to perform cyclic redundancy check on the test data.

[0034] In this embodiment, after generating the test data, the host sends the test data to the eMMC device under test through its eMMC controller module. In Implementation Method 1, the host sends a non-standard length data packet; in Implementation Method 2, the host sends commands or data with waveform distortion due to GPIO interference.

[0035] Step S300: Receive feedback data sent by the chip and obtain test results based on the feedback data.

[0036] In this embodiment, after receiving the test data, the eMMC device performs a CRC check on it according to the protocol. Since the test data is specially configured, the check result will inevitably fail. The eMMC device, based on its internal design, generates a test result indicating a CRC error and returns it to the host via the bus. The host receives this test result.

[0037] In this embodiment, if the test result indicates that the chip has a cyclic redundancy check error when performing cyclic redundancy check based on the test data, then the chip is determined to have passed the test.

[0038] In this embodiment, the host parses the received test results. If the test results clearly indicate the occurrence of a CRC error, it proves that the eMMC device has successfully detected the injected error. This indicates that its CRC check function is normal and can correctly report errors. Therefore, it can be determined that the eMMC device passed this error injection test. Conversely, if the device fails to report a CRC error, it indicates that its error detection mechanism may be defective, and the test failed.

[0039] Furthermore, in Implementation Method 2, after a CRC error is triggered, in order not to affect subsequent normal communication tests, the Host software will immediately restore the drive strength of the GPIO pin to the normal level through the register, thereby ensuring that it does not interfere with other commands or data.

[0040] This embodiment employs a software-level error injection strategy to achieve controllable and repeatable CRC error injection into chips such as eMMC, SD cards, and TF cards from the host side. This transforms the test from a "random phenomenon" into a "certain phenomenon," significantly improving the repeatability of test results and the reliability of verification. This method requires no expensive dedicated hardware, only minor code modifications and simple connections, greatly reducing the testing threshold and cost. Simultaneously, it avoids the system risks associated with traditional physical interference methods, possessing extremely high security and application value.

[0041] In some embodiments, the error injection strategy includes at least one of a first error injection strategy and a second error injection strategy; The first error injection strategy includes dynamically adjusting the target drive strength to process the data to be processed into distorted data; The second error injection strategy includes processing the data to be processed into data that does not meet the target protocol.

[0042] In this embodiment, the error injection strategy can be specified as at least two independent and flexibly selectable error injection strategies, namely, a first error injection strategy and a second error injection strategy. These two strategies achieve accurate triggering of Cyclic Redundancy Check (CRC) errors from different technical perspectives, providing testers with diverse testing methods.

[0043] Specifically, the first error injection strategy generates distorted data by precisely and programmably physically interfering with the hardware signal waveform through software instructions. First, hardware preparation is performed by shorting a configurable drive strength general-purpose input / output (GPIO) pin of the electronic device (Host side) to a target communication line (such as the command line CMD or data line DAT) of the eMMC device via a jumper wire. When an error needs to be injected, the Host-side software dynamically and instantaneously increases the drive strength of this GPIO pin (e.g., from a baseline strength of 2mA to 8mA or 12mA) by directly writing to the hardware configuration register while sending the target command or data to the eMMC. Because this GPIO pin is physically shorted to the target communication line, this sudden change in drive strength creates a strong "pull" effect on the transmitted signal, causing waveform distortion, such as overshoot, ringing, or unexpected level transitions. This interfered and distorted signal waveform constitutes the "distorted data." When the eMMC device samples this distorted data, its internal CRC check logic determines that the data transmission is incorrect, thus reliably triggering a CRC error. This strategy is universally applicable and works regardless of whether the command line is operating in push-pull or open-drain mode, enabling precise error injection for any specified command or data transmission.

[0044] The second error injection strategy leverages the timing and data integrity requirements of the eMMC protocol. It generates a corrupted data packet that fails to meet protocol requirements through software configuration. Here, the "target protocol" refers to the eMMC communication protocol. The host software configures the Direct Memory Access (DMA) controller to transmit only one valid data segment (e.g., 200 bytes) less than 512 bytes. After the DMA completes this 200-byte data transfer, the host does not turn off the clock (CLK) signal. For the eMMC device, as long as the clock is valid, it must continuously sample from the data lines. Therefore, it misinterprets subsequent static levels on the data lines (where the data lines remain high or low due to the DMA stop transmitting) as valid data. Ultimately, the eMMC device actually receives a complete 512-byte data block, but its content consists of "200 bytes of valid data + 312 bytes of invalid static data." The eMMC hardware performs a CRC check on this supposedly complete 512-byte data block. The host's CRC is incorrect because it is all 0s or all 1s. However, the CRC calculated by eMMC is correct. eMMC calculates a correct CRC value based on 200 bytes of valid data + 312 bytes of invalid data. This CRC value is then compared with all 0s / all 1s. The CRC check will fail 100% of the time, and the eMMC device will immediately report a CRC error. The second error injection strategy can be implemented entirely through software configuration, without any additional hardware connection. It is simple, direct, and highly reliable.

[0045] In some embodiments, step S100 may include but is not limited to the following steps: Upon receiving the first instruction, process the data to be processed according to the first error injection policy to obtain the test data; wherein, the first instruction is used to indicate triggering a cyclic redundancy check error during data transmission, or triggering a cyclic redundancy check error when sending a target command.

[0046] In this embodiment, as[[ID=__]] Figure 2 shown, the electronic device (Host side) is not only connected to the embedded multimedia card (eMMC) to be tested through standard command lines (CMD), data lines (DAT), and clock lines (CLK), but also includes a key hardware setting: a general-purpose input / output (GPIO) pin of the electronic device is short-circuited with a target communication line of the embedded multimedia card.

[0047] Specifically, the target communication line can be a command line (CMD) or a data line (DAT). When the target communication line is CMD, it is used to test the eMMC's ability to handle command CRC errors; when the target communication line is DAT, it is used to test its ability to handle data CRC errors, which can be used as an effective supplement to the foregoing DMA scheme.

[0048] In this embodiment, the Host controller receives the first instruction from the test software. The first instruction is used to indicate that the test system starts a CRC error injection process. This instruction can specify the specific scenario for triggering the error, that is, triggering a cyclic redundancy check error during data transmission, or triggering a cyclic redundancy check error when sending a target command. This enables the tester to precisely select the communication link to be verified. The first instruction can be manually issued by the tester through the test terminal, automatically generated by the electronic device based on a preset test process, or triggered by an external control signal.

[0049] It should be noted that there seems to be a missing number in the "ID=__" in the original text. I've left it as is in the translation for now. If there's a correction needed there, the translation can be adjusted accordingly.When the host controller is ready to send the target command or perform pending data transmission via the target communication line, the software begins error configuration. Before the test begins, a configurable drive strength GPIO pin on the host side is shorted to the selected target communication line (such as the CMD line) via a jumper wire, and this GPIO pin is preset to a high-level output. When the first instruction indicates that a CRC error should be injected for a specific command (such as the CMD18 read command), the host software executes a highly optimized code sequence. This sequence directly manipulates the low-level registers of the host hardware, first configuring the eMMC controller to send the target command, and then writing to the GPIO drive strength configuration register within a nanosecond time window. This "one line of code sends the command, the next line of code calls the drive" approach ensures that the GPIO drive strength adjustment is effective before the target command signal waveform has been fully transmitted.

[0050] Software commands can instantly increase the drive strength of GPIO pins shorted to the target line, for example, drastically increasing it from the default 2mA level to 8mA or 12mA. This sudden change in drive strength creates a strong "pull" effect on the signal on the target communication line, causing waveform distortion, such as overshoot, ringing, or unexpected level transitions. Once the eMMC device samples this distorted waveform on the target communication line, it identifies it as a CMD CRC error or a DATA CRC error and records the corresponding error status. The waveform of a CMD CRC error caused by the GPIO signal is shown below. Figure 3 As shown.

[0051] This embodiment transforms uncontrollable physical layer hardware interference into fully programmable software instructions and precisely controls the timing of changes in drive strength, enabling near 100% reliable triggering of CRC errors on any specified command or data transmission. It is compatible with both push-pull and open-drain transmission modes of eMMC commands, and the target communication line can be flexibly selected as either the CMD line or the DATA line. It is suitable for various devices that comply with the eMMC protocol, providing unprecedented accuracy and controllability for verifying the error recovery mechanism of eMMC devices.

[0052] In some embodiments, processing the data to be processed according to the first error injection strategy to obtain the test data may include, but is not limited to, the following steps: Before sending the data to be processed to the chip through the target communication line, the general-purpose input / output pin is configured with a first drive strength; After sending the data to be processed to the chip through the target communication line and before the transmission is completed, a preset command is written to the configuration register of the electronic device to increase the drive strength of the general-purpose input / output pin from the first drive strength to the second drive strength, thereby obtaining the test data.

[0053] In this embodiment, before sending the data to be processed to the embedded multimedia card via the target communication line, the host software first performs an initialization configuration. This configuration includes setting the general-purpose input / output (GPIO) pin to a first drive strength. The first drive strength is typically a low, default drive level (e.g., 2mA) to ensure that the GPIO pin does not have a significant electrical impact on the target communication line during non-testing periods, maintaining stable system operation. Simultaneously, the GPIO pin can be preset to a high-level output to prepare for subsequent increases in drive strength.

[0054] In this embodiment, after the transmission process of sending target commands or data to the eMMC via the target communication line is initiated at the host end, and before the transmission is completed, the host software performs a crucial operation: writing a preset command to the configuration register of the electronic device to increase the drive strength of the general-purpose input / output pin from the first drive strength to the second drive strength. The second drive strength is a level significantly higher than the first drive strength (e.g., a sudden increase from 2mA to 8mA or 12mA), and its magnitude is limited to generating sufficient signal interference without damaging the chip hardware (the specific level is determined by the hardware specifications of the electronic device). This instantaneous jump in drive strength will generate a strong current drive capability on the GPIO pin shorted to the target communication line. This abrupt drive capability will have a strong "pulling" effect on the signal on the target communication line, causing distortion of its level waveform, such as overshoot, ringing, or unexpected level jumps.

[0055] Specifically, the time window between transmission and completion is an extremely short nanosecond interval. For example, for a 48-bit CMD18 command, this window might only be a few hundred nanoseconds. The host software must switch the drive strength within this window to ensure effective interference with the transmitted signal waveform. The default command is not a high-level application programming interface (API) call, but a low-level instruction that writes directly to the host system-on-a-chip (SoC) hardware registers. By bypassing complex function calls and driver encapsulation and directly manipulating hardware registers, the latency from software instruction to hardware effect can be minimized, thus meeting the stringent requirements of nanosecond-level timing control.

[0056] This embodiment precisely matches the signal transmission timing by adjusting the drive intensity in stages, thus accurately limiting the interference of drive intensity to within the transmission cycle of the target command or data, ensuring the targeting and timeliness of error injection; by writing preset commands to the configuration register to directly control the hardware, the delay of the software operating system is bypassed, and the instantaneous change of drive intensity is achieved, which is the key technology for achieving nanosecond-level precise control.

[0057] In some embodiments, after increasing the drive strength of the general-purpose input / output pin from the first drive strength to the second drive strength, the steps may include, but are not limited to, the following: After the data to be processed is sent to the chip through the target communication line, the drive strength of the general-purpose input / output pin is restored from the second drive strength to the first drive strength to avoid affecting subsequent normal communication.

[0058] In this embodiment, after the process of increasing the drive strength of the general purpose input / output pin from the first drive strength to the second drive strength and successfully triggering the CRC error is completed, the software can write to the configuration register again to restore the GPIO drive strength to the first drive strength or a lower default value to ensure that subsequent normal communication is not affected.

[0059] Specifically, after confirming that the target command or data transmission has ended (e.g., receiving a response from the eMMC or completing a data transmission interruption), the host software writes a preset command to the configuration register of the electronic device again, resetting the drive strength level of the GPIO pin to the first drive strength. This drive strength restoration ensures that the error injection operation is a one-time event. It strictly limits the effective scope of signal interference, targeting only the preset target command or data to be processed, thus completely avoiding accidental interference with subsequent unrelated normal commands or data transmissions due to the GPIO being continuously in a high drive strength state, ensuring the purity of the test sequence and the stability of the system state.

[0060] This embodiment restores the drive strength promptly after transmission ends, avoiding erroneous interference with subsequent normal command / data transmission. It supports multiple rounds of continuous testing (such as error recovery mechanisms for batch verification of multiple commands and multiple data blocks), significantly improving testing efficiency. The recovery step adopts the same register direct write method as the boosting step, requiring no additional hardware configuration or complex software logic. It can be seamlessly integrated with the original test process, reducing the complexity of test implementation.

[0061] In some embodiments, the electronic device establishes a communication connection with the embedded multimedia card (eMMC) via a command line (CMD), a data line (DATA), and a clock line (CLK). These three lines respectively handle command transmission, data transmission, and clock synchronization, providing a basic communication link for the normal operation of the eMMC. Step S100 may also include, but is not limited to, the following steps: Upon receiving the second instruction, the data to be processed is processed according to the second error injection strategy to obtain the test data; The second instruction is used to instruct a cyclic redundancy check error to be triggered during data transmission; The data to be processed is processed according to the second error injection strategy, including: The data packets to be processed are modified to contain M bytes of valid data and N bytes of invalid data, wherein the sum of M and N satisfies the byte size required by the target protocol.

[0062] In addition, during the test, a continuous clock signal was provided to the embedded multimedia card via a clock line.

[0063] In this embodiment, the second instruction is used to instruct the triggering of a cyclic redundancy check (CRC) error during data transmission. The second instruction can be a command actively triggered by testers through a test script or user interface, or it can be a control instruction issued by an automated testing framework when executing test cases. Its core function is to initiate a specific test process designed to verify the DATACRC error handling capability of the eMMC device.

[0064] Specifically, the DMA controller is configured as follows: the software code directly writes instructions to the DMA controller register on the host side, setting the length of the data packet to be transmitted to a non-standard N bytes. N is a positive integer that is not a multiple of 512, such as 200 bytes, 300 bytes, etc. This violates the basic requirements of the eMMC protocol for data length.

[0065] While configuring the data length, it is crucial to ensure the clock (CLK) signal remains active throughout the entire data transmission cycle. This is because the host-side clock generation module and DMA controller are independent hardware units. The DMA controller handles data transfer, while the clock module provides the communication clock. Therefore, even if the DMA controller is configured to transmit only N bytes of data, the host can still maintain the clock signal output, keeping the eMMC device in an active communication state.

[0066] With the above configuration, the generated test data is a non-standard data packet of N bytes in length, transmitted under a continuous clock signal. When the host sends this test data to the eMMC device, the eMMC device continuously receives data driven by the clock signal, but data transmission stops after receiving N bytes of data. Since the received data volume is far less than the protocol's expected minimum unit of 512 bytes, the eMMC device's internal logic determines that the data packet has abnormally ended and immediately performs a CRC check on the received N bytes of data. Because this data packet is an intentionally constructed, non-standard length "malformed" data packet, its CRC check result will inevitably be incorrect. Therefore, the eMMC device generates a test result indicating a DATA CRC error and returns it to the host via the command line (CMD). The waveform indicating a DATA CRC error is shown below. Figure 4 As shown.

[0067] This embodiment achieves this by configuring the DMA controller through software, without any external physical interference. It can reliably trigger DATA CRC errors with a 100% success rate, transforming the test from a "random phenomenon" to a "certain phenomenon," greatly improving the controllability, repeatability, and verification efficiency of the test.

[0068] This application's embodiments innovatively implement pure software, dual-path CRC error control injection into the CMD and DATA channels of eMMC devices from the host side, filling a technological gap in the industry. This method transforms uncontrollable physical interference into programmable software instructions, achieving nearly 100% error triggering reliability, turning testing from a "random phenomenon" into a "certain phenomenon," greatly improving the repeatability and credibility of test results. Simultaneously, this solution features zero cost, high ease of use, and high security. It requires no dedicated hardware, only minor code modifications and a single jumper wire for implementation, and avoids the risk of system deadlock or device damage that may result from traditional hardware interference. Therefore, this technology can be widely applied across the entire industry chain, including eMMC controller design, driver development, and firmware reliability testing, significantly enhancing product testing coverage and quality assurance.

[0069] Please see Figure 5 This application also provides a chip testing apparatus 500, which can implement the above-described chip testing method. The apparatus includes: Processing module 10 is used to process the data to be processed according to a preset error injection strategy to obtain test data. The error injection strategy is used to process the data to be processed into distorted data and / or data that does not meet the target protocol. The sending module 20 is used to send the test data to the chip under test, so as to instruct the chip under test to perform cyclic redundancy check on the test data; The receiving module 30 is used to receive feedback data sent by the chip and obtain test results based on the feedback data.

[0070] In some implementations, the error injection strategy includes at least one of a first error injection strategy and a second error injection strategy; The first error injection strategy includes dynamically adjusting the target drive strength to process the data to be processed into distorted data; The second error injection strategy includes processing the data to be processed into data that does not meet the target protocol.

[0071] In some implementations, the processing module 10 may include: The first processing submodule is configured to process the data to be processed according to the first error injection strategy upon receiving a first instruction, thereby obtaining the test data; wherein the first instruction is configured to instruct the triggering of a cyclic redundancy check error during data transmission, or to trigger a cyclic redundancy check error when sending a target command.

[0072] In some implementations, a general-purpose input / output pin on the electronic device testing the chip is shorted to a target communication line of the chip; the first processing submodule may include: A first configuration unit is configured to set the general-purpose input / output pin to a first drive strength before sending the data to be processed to the chip through the target communication line; The second configuration unit is used to write a preset command to the configuration register of the electronic device after sending the data to be processed to the chip through the target communication line and before the transmission is completed, to increase the drive strength of the general-purpose input / output pin from the first drive strength to the second drive strength, so as to obtain the test data.

[0073] In some implementations, the first processing submodule may further include: The recovery unit is used to restore the drive strength of the general-purpose input / output pin from the second drive strength to the first drive strength after the data to be processed is sent to the embedded multimedia card through the target communication line, so as to avoid affecting subsequent normal communication.

[0074] In some embodiments, the processing module 10 may further include: The second processing submodule is used to process the data to be processed according to the second error injection strategy upon receiving the second instruction, thereby obtaining the test data; wherein, the second instruction is used to instruct the triggering of a cyclic redundancy check error during data transmission; the data packets included in the data to be processed are modified to contain M bytes of valid data and N bytes of invalid data, wherein the sum of M and N satisfies the byte size required by the target protocol.

[0075] In some implementations, a continuous clock signal is provided to the chip during testing.

[0076] The specific implementation of this chip testing device is basically the same as the specific implementation of the chip testing method described above, and will not be repeated here.

[0077] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described chip testing method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0078] Please see Figure 6 , Figure 6 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 601 can be implemented using a general-purpose central processing unit (CPU), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 602 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 602 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 602 and is called and executed by the processor 601 using the chip testing method of the embodiments of this application. The input / output interface 603 is used to implement information input and output; The communication interface 604 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 605 transmits information between various components of the device (e.g., processor 601, memory 602, input / output interface 603, and communication interface 604); The processor 601, memory 602, input / output interface 603, and communication interface 604 are connected to each other within the device via bus 605.

[0079] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described chip testing method.

[0080] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0081] The chip testing method, chip testing device, electronic device, and storage medium provided in this application embodiment process the data to be processed to generate test data through a preset error injection strategy. After sending the test data to the embedded multimedia card under test, the method receives the test result obtained by the card performing cyclic redundancy check (CRC) based on the test data. If the result indicates that there is a CRC check error, the embedded multimedia card is determined to have passed the test. Its technical effect is that it can specifically verify the effectiveness of the CRC check function of the embedded multimedia card, ensuring that the device can accurately identify erroneous data when it encounters it in actual data transmission. At the same time, the test logic is simple and highly targeted, effectively improving the test efficiency and the reliability of the test results.

[0082] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0083] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0084] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0085] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0086] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0087] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0088] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0089] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0090] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0091] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0092] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A chip testing method, characterized in that, The method includes: The data to be processed is processed according to a preset error injection strategy to obtain test data. The error injection strategy is used to process the data to be processed into distorted data and / or data that does not meet the target protocol. The test data is sent to the chip under test to instruct the chip under test to perform cyclic redundancy check on the test data. The system receives feedback data sent by the chip and obtains test results based on the feedback data.

2. The method according to claim 1, characterized in that, The error injection strategy includes at least one of a first error injection strategy and a second error injection strategy; The first error injection strategy includes dynamically adjusting the target drive strength to process the data to be processed into distorted data; The second error injection strategy includes processing the data to be processed into data that does not meet the target protocol.

3. The method according to claim 2, characterized in that, The data to be processed is processed according to a preset error injection strategy to obtain test data, including: Upon receiving the first instruction, the data to be processed is processed according to the first error injection strategy to obtain the test data; The first instruction is used to indicate whether a cyclic redundancy check error is triggered during data transmission or when a target command is sent.

4. The method according to claim 3, characterized in that, A general-purpose input / output pin on the electronic device used to test the chip is shorted to a target communication line of the chip; The data to be processed is processed according to the first error injection strategy to obtain the test data, including: Before sending the data to be processed to the chip through the target communication line, the general-purpose input / output pin is configured with a first drive strength; After sending the data to be processed to the chip through the target communication line and before the transmission is completed, a preset command is written to the configuration register of the electronic device to increase the drive strength of the general-purpose input / output pin from the first drive strength to the second drive strength, thereby obtaining the test data.

5. The method according to claim 4, characterized in that, After increasing the drive strength of the general-purpose input / output pin from the first drive strength to the second drive strength, the method further includes: After the data to be processed is sent to the chip through the target communication line, the drive strength of the general-purpose input / output pin is restored from the second drive strength to the first drive strength to avoid affecting subsequent normal communication.

6. The method according to claim 2, characterized in that, The data to be processed is processed according to a preset error injection strategy to obtain test data, including: Upon receiving the second instruction, the data to be processed is processed according to the second error injection strategy to obtain the test data; The second instruction is used to instruct a cyclic redundancy check error to be triggered during data transmission; The data to be processed is processed according to the second error injection strategy, including: The data packets to be processed are modified to contain M bytes of valid data and N bytes of invalid data, wherein the sum of M and N satisfies the byte size required by the target protocol.

7. The method according to claim 6, characterized in that, A continuous clock signal is provided to the chip during the test.

8. A chip testing device, characterized in that, The device includes: The processing module is used to process the data to be processed according to a preset error injection strategy to obtain test data. The error injection strategy is used to process the data to be processed into distorted data and / or data that does not meet the target protocol. The sending module is used to send the test data to the chip under test, so as to instruct the chip under test to perform cyclic redundancy check on the test data; The receiving module is used to receive feedback data sent by the chip and obtain test results based on the feedback data.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the chip testing method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the chip testing method according to any one of claims 1 to 7.

Images