Test methods, apparatus, electronic devices and storage media for chip multi-boot modes

Abstract

This application discloses a testing method, apparatus, electronic device, and storage medium for multiple boot modes of a chip, relating to the field of chip prototype verification technology. The method includes receiving a boot mode setting command sent by a host computer, controlling the chip prototype under test (DUT) to be in a reset state, and determining a target boot mode. If the target boot mode is a boot mode based on a first boot medium or a boot mode based on a second boot medium, a target selector is controlled to switch the signal line of the first or second boot medium to the DUT side. Based on the target boot mode, the level state of the boot pin of the DUT is adjusted, and the reset state of the DUT is released, so that the DUT boots based on the target boot mode. Based on the boot log of the DUT, the test result of the DUT under the target boot mode is determined. This achieves the technical effect of improving testing efficiency.

Description

Technical Field

[0001] This application relates to the field of chip prototype verification technology, and in particular to a test method, apparatus, electronic device and storage medium for chip multi-boot modes. Background Technology

[0002] With the increasing demand for flexibility and reliability in boot modes in applications such as embedded systems, IoT, and server management units, on-chip systems (SoCs) and microcontrollers typically support multiple boot modes. During the chip prototyping phase of an SoC or microcontroller, each boot mode needs rigorous testing to ensure that the primary bootloader (BootROM) can correctly identify the boot mode and load the corresponding secondary bootloader image. Related technologies include methods for testing multiple boot modes during chip prototyping: 1. Manually connecting different boot media to the chip prototype to switch to the desired boot mode for testing. 2. Manually switching jumpers or DIP switches to pull the boot pin high / low to switch to the desired boot mode for testing. Both of these methods require powering down and then powering back on the chip prototype after each boot mode change so that the BootROM can reread the boot pin status to determine the boot mode or detect the boot media physically connected to the chip prototype to determine the boot mode.

[0003] This method of testing multiple boot modes relies heavily on manual switching of jumpers, DIP switches, replacement of boot media, and repeated power-on / off operations, resulting in low testing efficiency and a high risk of errors. Summary of the Invention

[0004] This application provides a testing method, apparatus, electronic device, and storage medium for multiple boot modes of chips, in order to at least solve the problems in related technologies where the testing of multiple boot modes is highly dependent on manual switching of jumpers, DIP switches, replacement of boot media, and repeated power-on and power-off operations, resulting in low testing efficiency and easy errors.

[0005] This application provides a testing method for multiple boot modes of a chip, applied to a target microcontroller, including: Receive the startup mode setting command sent by the host computer and control the prototype chip under test to be in a reset state; Determine the target boot mode based on the boot mode setting command; When the target boot mode is either a boot mode based on the first boot medium or a boot mode based on the second boot medium, the target selector switches the signal line of the first boot medium or the signal line of the second boot medium to the side of the chip under test prototype. Based on the target boot mode, the level state of the boot pin of the chip under test prototype is adjusted to release the reset state of the chip under test prototype so that the chip under test prototype can restart, run the first-level boot program, read the second-level boot program image from the first boot medium or the second boot medium, and complete the boot of the chip under test prototype based on the second-level boot program image. Based on the startup logs of the prototype chip under test, the test results of the prototype chip under test in the target startup mode are determined.

[0006] This application also provides a test apparatus for chip multi-boot modes, including: The receiving module is used to receive the start mode setting command sent by the host computer and control the prototype chip under test to be in a reset state. The first determining module is used to determine the target boot mode based on the boot mode setting instruction; The first startup module is used to control the target selector to switch the signal line of the first startup medium or the signal line of the second startup medium to the chip under test prototype side when the target startup mode is a startup mode based on the first startup medium or a startup mode based on the second startup medium. Based on the target startup mode, it adjusts the level state of the startup pin of the chip under test prototype, releases the reset state of the chip under test prototype, so that the chip under test prototype restarts, runs the first-level boot program, reads the second-level boot program image from the first startup medium or the second startup medium, and completes the startup of the chip under test prototype based on the second-level boot program image. The second determination module is used to determine the test results of the chip prototype under test in the target startup mode based on the startup log of the chip prototype under test.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the test method of any of the above-described chip multi-boot modes when executing the computer program.

[0008] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the test method for any of the above-described chip multi-boot modes.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the test method for any of the above-described chip multi-boot modes.

[0010] Through this application, the target microcontroller receives a startup mode setting instruction sent by the host computer and controls the prototype chip under test (DUT) to be in a reset state; based on the startup mode setting instruction, the target startup mode is determined; when the target startup mode is a startup mode based on a first startup medium or a startup mode based on a second startup medium, the target selector switches the signal line of the first startup medium or the signal line of the second startup medium to the DUT prototype side, and adjusts the level state of the startup pin of the DUT prototype based on the target startup mode, releasing the reset state of the DUT prototype so that the DUT prototype restarts, runs the first-level boot program, reads the second-level boot program image from the first startup medium or the second startup medium, and completes the startup of the DUT prototype based on the second-level boot program image; based on the startup log of the DUT prototype, the test results of the DUT prototype in the target startup mode are determined. By sending startup mode setting commands to the host computer, the target microcontroller switches the startup mode of the prototype chip under test (DUT) without manual intervention. After each startup mode switch, there's no need to power off and then power on the prototype chip; multiple startup modes can be tested continuously and automatically after a single power-on. Therefore, this method solves the technical problems of low testing efficiency and error-proneness in related technologies for testing multiple startup modes, achieving improved testing efficiency and accuracy. Attached Figure Description

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

[0012] Figure 1 This is a flowchart illustrating a method for testing various startup modes in related technologies. Figure 2 A schematic diagram of the structure of a chip multi-boot mode test system provided in an embodiment of this application; Figure 3 A flowchart illustrating a chip multi-boot mode testing method provided in an embodiment of this application; Figure 4 A flowchart illustrating another chip multi-boot mode testing method provided in this application embodiment; Figure 5 A flowchart illustrating another chip multi-boot mode testing method provided in an embodiment of this application; Figure 6 A schematic diagram of a chip multi-boot mode testing device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0014] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0015] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0016] With the increasing demand for flexibility and reliability in boot modes in applications such as embedded systems, IoT, and Baseboard Management Controllers (BMCs), modern System-on-Chip (SoC) or Microcontroller Units (MCUs) typically support multiple boot modes. For example: Boot mode based on Serial Peripheral Interface Flash Memory (SPI Flash): A secondary bootloader image (such as U-Boot or Bootloader) is stored in external SPI NOR / NAND Flash, allowing the SoC or MCU to load and execute the image, thus booting the entire system. Boot mode based on embedded MultiMediaCard (eMMC) / Secure Digital (SD) cards: The secondary bootloader image and file system are placed on the eMMC or SD card, allowing the SoC or MCU to load and execute the image, thus booting the entire system. Boot mode based on Universal Asynchronous Receiver / Transmitter (UART): After power-on or reset, the BootROM listens for UART serial port data, downloads a secondary bootloader image from an external host, executes the secondary bootloader image, and starts the entire system. Network-based boot mode: The secondary bootloader image is downloaded from a network server via an Ethernet interface, executed, and starts the entire system. Network-based boot mode can be either Ethernet-based or Trivial File Transfer Protocol (TFTP)-based.

[0017] During the chip prototype verification phase of a system-on-a-chip (SoC) or microcontroller, R&D and quality engineers need to repeatedly verify each of the above-mentioned boot modes to ensure that the BootROM can correctly detect and load the secondary boot program image under different boot media (i.e., SPI Flash, eMMC or SD card, UART) and different boot pin level configurations. Related technologies include methods for testing multiple boot modes during the chip prototype verification phase: 1. Manually connecting different boot media to the chip prototype to switch to the required boot mode for testing. 2. Manually switching jumpers or DIP switches to pull the boot pin high / low to switch to the required boot mode for testing. Boot pins include BOOT0 and BOOT1. Understandably, when switching boot modes, test engineers need to manually switch jumpers, DIP switches, or replace the onboard card to verify another boot mode. After each change of boot mode, the chip prototype needs to be completely powered off (the development board power is turned off) and then powered on again so that the BootROM can reread the boot pin status to determine the boot mode or detect the boot media physically connected to the chip prototype to determine the boot mode.

[0018] Figure 1 This is a flowchart of a method for testing multiple startup modes in related technologies, such as... Figure 1 As shown, the process includes: Powering off the development board, i.e., powering off the control chip prototype. Burning the image to the target storage medium: Determining the target storage medium based on the current boot mode under test. When updating the secondary bootloader image in the target storage medium is required, the updated secondary bootloader image is burned to the target storage medium. Modifying the corresponding DIP switches or jumpers according to the test cases: Modifying the corresponding DIP switches or jumpers according to the current boot mode under test to change the level of the Boot pin, so that the development board can resample the state of the Boot pin after powering back on, and determine the current boot mode under test. Powering on and waiting for results: Powering back on the development board and waiting for the boot result. Manually judging the result: After the development board is powered back on, the test engineer needs to check the BootROM / U-Boot output log through the serial terminal or observe the status of the indicator lights (LEDs) on the board to determine whether the development board "successfully entered the secondary bootloader image" or "loaded the operating system" to determine the boot result. Performing the next test case test: That is, performing the test for the next boot mode, returning to the step of powering off the development board.

[0019] Understandably, the methods used in related technologies to test multiple boot modes rely heavily on manual switching of jumpers, DIP switches, replacement of boot media, and repeated power-on / off operations. This results in low testing efficiency, high error rates, and is unsuitable for automated testing scenarios. Furthermore, the repeated power-on / off processes not only increase testing time but also cause unnecessary power fluctuations and test interruptions to the entire chip prototype verification platform.

[0020] In related technologies, the method of manually judging the startup result is time-consuming and prone to subjective errors when there are many test cases.

[0021] To address the aforementioned issues, this application provides a testing method, apparatus, electronic device, and storage medium for multiple boot modes of a chip. The method includes: receiving a boot mode setting instruction sent by a host computer and controlling the prototype chip under test (DUT) to be in a reset state; determining a target boot mode based on the boot mode setting instruction; when the target boot mode is a boot mode based on a first boot medium or a boot mode based on a second boot medium, controlling a target selector to switch the signal line of the first boot medium or the signal line of the second boot medium to the DUT prototype side, and adjusting the level state of the boot pin of the DUT prototype based on the target boot mode to release the reset state of the DUT prototype, so that the DUT prototype restarts, runs the first-level boot program, reads the second-level boot program image from the first boot medium or the second boot medium, and completes the boot of the DUT prototype based on the second-level boot program image; and determining the test result of the DUT prototype in the target boot mode based on the boot log of the DUT prototype. The method described above allows the target microcontroller to switch the startup mode of the chip prototype under test by sending a startup mode setting command from a host computer. This switching is done without manual intervention, and there's no need to power off and then power on the chip prototype after each mode switch. Multiple startup modes can be tested continuously and automatically after a single power-on. Therefore, this method solves the technical problems of low testing efficiency and error-proneness in related technologies for testing multiple startup modes, achieving improved testing efficiency and accuracy.

[0022] The specific application environment architecture or specific hardware architecture on which the test method for chip multi-boot mode depends is described here.

[0023] The chip multi-boot mode testing method, apparatus, electronic device, and storage medium provided in this application are applicable to testing multiple boot modes of chips. For example... Figure 2The diagram shows the structure of the chip multi-boot mode test system based on this application. This test system includes a host computer and a Field-Programmable Gate Array (FPGA) prototype verification platform. The FPGA prototype verification platform includes a target microcontroller, several selectors, a first boot medium, a second boot medium, and a prototype chip under test (DUT). The target microcontroller is connected to each boot pin (e.g., BOOT0, BOOT1, or BOOT_SEL) of the DUT prototype via general purpose input / output (GPIO) ports. The target microcontroller can force the voltage levels of these boot pins by outputting high, low, or tri-state (Hi-Z) signals, so that the BootROM of the DUT prototype can identify the boot mode based on the voltage levels of the boot pins during the next boot. The first boot medium can be SPI flash, and the second boot medium can be eMMC or an SD card. Figure 2 The following example uses eMMC as the second boot medium. The signal lines of the onboard first and second boot media are not directly connected to the prototype chip under test (DUT). Instead, they are connected to several selectors. Specifically, the signal lines of the first boot medium are connected to several first selectors, and the signal lines of the second boot medium are connected to several second selectors, with each signal line corresponding to one selector. The enable pins of these selectors are also controlled by the target microcontroller to ensure that only one of the target microcontroller or the prototype chip under test can access the specific memory within a given time window. The prototype chip under test can be a SoC or an MCU chip prototype.

[0024] Understandably, based on several first selectors, it is ensured that only one of the target microcontroller or the chip under test prototype can access the SPI flash through the SPI path within a certain time window. Based on several second selectors, it is ensured that only one of the target microcontroller and the chip under test prototype can access the eMMC through the eMMC path within a certain time window. The selector can be a multiplexer (MUX) or a tri-state buffer. In the embodiments of this application, a multiplexer is used as an example for description.

[0025] The host computer and the target microcontroller are connected via UART0. The transmit line of the target microcontroller's UART is connected to the receive line of the prototype chip under test's UART, that is, the target microcontroller and the prototype chip under test are connected via UART1.

[0026] The user can input the boot mode to be tested into the host computer. The host computer generates a boot mode setting command based on the boot mode and sends the command to the target microcontroller. The target microcontroller receives the boot mode setting command from the host computer and, upon receiving it, puts the prototype chip under test into a reset state. It should be noted that during the initial power-on phase, the target microcontroller's firmware will first complete its own initialization, setting all its GPIOs to output mode and establishing a communication link with the host computer, i.e., establishing a UART0 path. This communication link can also be a USB path.

[0027] The process of controlling the prototype chip under test (DUT) to be in a reset state includes: the target microcontroller locking the DUT prototype in a hardware reset state by pulling the hard reset (RESET) signal low or sending a soft reset command, ensuring that all its core logic and configurable registers are restored to a known initial level. The target microcontroller can either drive the hard reset signal of the DUT prototype, pulling it low and then releasing it, or initiate a soft reset command through the debug interface to meet the requirements of different boot modes for maintaining peripheral clock and power supplies.

[0028] The target microcontroller determines the target startup mode based on the startup mode setting instruction. If the target startup mode is based on either the first or second startup medium, the target selector switches the signal line of either the first or second startup medium to the prototype chip under test (DUT). Based on the target startup mode, the level of the startup pin of the DUT prototype is adjusted to release its reset state, causing it to restart and run its primary bootloader. The primary bootloader image is then read from either the first or second startup medium, and the startup of the DUT prototype is completed based on this image. Finally, the test results of the DUT prototype under the target startup mode are determined based on its startup log.

[0029] Understandably, when the target boot mode is a boot mode based on a first boot medium, the target selector is the first selector, which controls the first selector to switch the signal line of the first boot medium to the prototype side of the chip under test, so that the prototype chip under test can access the first boot medium. When the target boot mode is a boot mode based on a second boot medium, the target selector is the second selector, which controls the second selector to switch the signal line of the second boot medium to the prototype chip under test, so that the prototype chip under test can access the second boot medium.

[0030] When the target boot mode is a boot mode based on a third boot medium, if the transmit line of the asynchronous transceiver of the target microcontroller and the receive line of the asynchronous transceiver of the prototype chip under test are properly connected, then based on the target boot mode, the level of the boot pin of the prototype chip under test is adjusted to release the reset state of the prototype chip under test, causing the prototype chip under test to restart, run its first-level boot program, receive the second-level boot program image sent by the target microcontroller, and boot the prototype chip under test based on the second-level boot program image. The third boot medium is a UART. An asynchronous transceiver is a UART.

[0031] The target microcontroller can adjust the level of the startup pin of the prototype chip under test by sending a Boot pin signal, so that the prototype chip under test can recognize the adjusted level of the startup pin after restarting and determine the target startup mode.

[0032] Embodiments of this application provide a testing method for chip multi-boot modes, applied to the aforementioned target microcontroller. Figure 3 This is a flowchart illustrating the testing method for chip multi-boot modes provided in an embodiment of this application, as shown below. Figure 3 As shown, the test method for the multi-boot mode of this chip includes the following steps: Step S301: Receive the startup mode setting instruction sent by the host computer and control the prototype chip under test to be in a reset state.

[0033] As mentioned above, after receiving the startup mode setting instruction sent by the host computer, the target microcontroller locks the chip prototype under test in a hardware reset state by pulling down the hard reset signal or sending a soft reset command, so as to ensure that all its core logic and configurable registers are restored to the known initial level.

[0034] Step S302: Determine the target boot mode based on the boot mode setting instruction.

[0035] Step S303: When the target boot mode is a boot mode based on the first boot medium or a boot mode based on the second boot medium, control the target selector to switch the signal line of the first boot medium or the signal line of the second boot medium to the side of the chip under test prototype, and adjust the level state of the boot pin of the chip under test prototype based on the target boot mode to release the reset state of the chip under test prototype so that the chip under test prototype restarts, runs the first-level boot program, reads the second-level boot program image from the first boot medium or the second boot medium, and completes the boot of the chip under test prototype based on the second-level boot program image.

[0036] The first boot medium can be SPI flash, and the second boot medium can be eMMC or SD card. Specifically, when the target boot mode is based on the first boot medium, the target selector switches the signal lines of the first boot medium to the prototype chip under test (DUT) side. Based on the target boot mode, the level of the boot pin of the DUT prototype is adjusted to release the reset state of the DUT prototype, causing it to restart and run the first-level boot program. The second-level boot program image is read from the first boot medium, and the boot process of the DUT prototype is completed based on the second-level boot program image. The signal lines of the first boot medium include data lines.

[0037] When the target boot mode is based on the second boot medium, the target selector switches the signal lines of the second boot medium to the prototype chip under test (DUT) side. Based on the target boot mode, it adjusts the level of the boot pin of the DUT prototype, releasing its reset state to restart the prototype and run its primary boot program. The primary boot program then reads the secondary boot program image from the second boot medium and completes the boot process based on this image. The signal lines of the second boot medium include the command line (CMD), clock line (CLK), and data line (DAT). Specifically, the primary boot program loads the secondary boot program image from the boot partition of the second boot medium.

[0038] Understandably, the primary bootloader identifies the voltage level of the boot pin of the prototype chip under test, determines the target boot mode, reads the secondary bootloader image from the first or second boot medium based on the target boot mode, and completes the boot of the prototype chip under test based on the secondary bootloader image.

[0039] It should be noted that after adjusting the level of the startup pin of the prototype chip under test based on the target startup mode, wait for tens of milliseconds to ensure signal stability before releasing the reset signal of the prototype chip under test to restart it. The startup pin is also known as the Boot pin.

[0040] Step S304: Based on the startup log of the prototype chip under test, determine the test results of the prototype chip under test in the target startup mode.

[0041] The chip multi-boot mode testing method provided in this application embodiment switches the boot mode of the chip prototype under test by sending boot mode setting instructions from a host computer. This requires no manual intervention, and after each boot mode switch, there is no need to power off and then power on the chip prototype. Multiple boot modes can be tested continuously and automatically after a single power-on. Therefore, this method solves the technical problems of low testing efficiency and error-proneness in related technologies for testing multiple boot modes, achieving the technical effect of improving testing efficiency and accuracy.

[0042] Embodiments of this application provide a testing method for chip multi-boot modes, applied to the aforementioned target microcontroller. Figure 4 This is a flowchart illustrating the testing method for chip multi-boot modes provided in an embodiment of this application, as shown below. Figure 4 As shown, the test method for the multi-boot mode of this chip includes the following steps: Step S401: Receive the startup mode setting command sent by the host computer, and control the prototype chip under test to be in a reset state. For details, please refer to [link to relevant documentation]. Figure 3 Step S301 of the illustrated embodiment will not be described again here.

[0043] Step S402: Determine the target boot mode based on the boot mode setting command. For details, please refer to [link to relevant documentation]. Figure 3 Step S302 of the illustrated embodiment will not be described again here.

[0044] Step S403: When the target boot mode is either a boot mode based on the first boot medium or a boot mode based on the second boot medium, the target selector switches the signal line of the first boot medium or the signal line of the second boot medium to the prototype chip under test (DUT) side. Based on the target boot mode, the level state of the boot pin of the DUT prototype is adjusted to release the reset state of the DUT prototype, causing it to restart and run the first-level boot program. The second-level boot program image is read from the first boot medium or the second boot medium, and the boot of the DUT prototype is completed based on the second-level boot program image. For details, please refer to [link to details]. Figure 3 Step S303 of the illustrated embodiment will not be described again here.

[0045] Step S404: Based on the startup log of the prototype chip under test, determine the test results of the prototype chip under test in the target startup mode.

[0046] Specifically, step S404 includes: Step S4041: Collect the startup log output by the prototype chip under test during the startup process.

[0047] After the target microcontroller releases the reset state of the prototype chip under test, it enters the log listening state and collects the boot log output by the BootROM or secondary boot program image of the prototype chip under test through the UARTRx (receive) port.

[0048] Step S4042: Based on multiple successful startup keywords and startup logs, determine the test results of the chip prototype under test in the target startup mode.

[0049] The key for successful startup is set by technical personnel based on their experience.

[0050] After determining the test results of the prototype chip under test in the target boot mode, the test results are sent to the host computer.

[0051] The chip multi-boot mode testing method provided in this application eliminates the need for testers to visually inspect the serial port terminal or indicator lights to determine successful booting. The target microcontroller automatically completes log collection, analysis, and matching, achieving unattended judgment and seamless integration with the entire automated testing process. Using a pre-defined and explicit keyword list for matching avoids subjective judgment, ensuring absolute consistency in judgment standards each time, and improving the reliability and repeatability of test results.

[0052] In some optional implementations, the test method for the chip multi-boot mode further includes the following: before the control target selector switches the signal line of the first boot medium or the signal line of the second boot medium to the prototype side of the chip under test: Step a1: If a flashing image instruction is received from the host computer, the target secondary boot program image is obtained based on the flashing image instruction.

[0053] Understandably, if a user needs to update the secondary bootloader image in the boot media, the host computer responds to the user's image flashing operation by sending an image flashing command to the target microcontroller. The target microcontroller receives the image flashing command from the host computer and obtains the target secondary bootloader image.

[0054] Step a2: Control the target selector to switch the signal line of the first startup medium or the signal line of the second startup medium to the target microcontroller side.

[0055] When the target boot mode is a boot mode based on the first boot medium, the first selector is controlled to switch the signal line of the first boot medium to the target microcontroller side so that the target microcontroller can access the first boot medium.

[0056] When the target boot mode is a boot mode based on the second boot medium, the control of the second selector switches the signal line of the second boot medium to the target microcontroller side so that the target microcontroller can access the second boot medium.

[0057] Step a3: Update the original secondary bootloader image in the first boot medium or the second boot medium using the target secondary bootloader image.

[0058] When the target boot mode is a boot mode based on the first boot medium, the original secondary boot program image in the first boot medium is updated using the target secondary boot program image.

[0059] When the target boot mode is a boot mode based on the second boot medium, the original secondary boot program image in the second boot medium is updated using the target secondary boot program image.

[0060] Step a4: After the update is completed, control the target selector to switch the signal line of the first startup medium or the signal line of the second startup medium to the prototype side of the chip under test.

[0061] When the target boot mode is a boot mode based on the first boot medium, after updating the original secondary boot program image in the first boot medium based on the target secondary boot program image, the first selector is controlled to switch the signal line of the first boot medium to the prototype side of the chip under test.

[0062] When the target boot mode is a boot mode based on the second boot medium, after updating the original secondary boot program image in the second boot medium based on the target secondary boot program image, the second selector is controlled to switch the signal line of the second boot medium to the prototype side of the chip under test.

[0063] The chip multi-boot mode testing method provided in this application automates the time-consuming and manual "image burning" step in traditional testing. Through exclusive access control that "first switches to the target microcontroller side," the chip prototype under test is completely isolated during the update process, preventing data conflicts, bus contention, or programming failures caused by the chip prototype simultaneously accessing the boot medium during burning. This fundamentally ensures the reliability of the programming operation and the physical security of the boot medium.

[0064] In some optional implementations, the transmit line of the target microcontroller's asynchronous transceiver is connected to the receive line of the prototype chip under test's asynchronous transceiver. The communication parameters of the target microcontroller's asynchronous transceiver are set to be the same as the target communication parameters in the prototype chip under test's primary bootloader. The communication parameters are the baud rate (e.g., 115200). The asynchronous transceivers of both the target microcontroller and the prototype chip under test are prepared according to the baud rate specified in the prototype chip under test's primary bootloader manual.

[0065] The test methods for the above-mentioned chip multi-boot modes also include: Step b1: If the target boot mode is a boot mode based on a third boot medium, and the connection between the transmit line of the asynchronous transceiver of the target microcontroller and the receive line of the asynchronous transceiver of the prototype chip under test is normal, then based on the target boot mode, adjust the level of the boot pin of the prototype chip under test, release the reset state of the prototype chip under test, so that the prototype chip under test restarts, runs the first-level boot program, receives the second-level boot program image sent by the target microcontroller, and completes the boot of the prototype chip under test based on the second-level boot program image.

[0066] The third boot medium is UART. The boot mode based on this third boot medium does not rely on memory signal lines; instead, it causes the prototype chip under test to enter a state of waiting for image download from the UART serial port during the BootROM stage.

[0067] When the UART serial port is open, the target microcontroller, based on the target boot mode, adjusts the level of the boot pin of the prototype chip under test (DUT). By pulling the hard reset signal of the DUT prototype high, the DUT prototype is released from its reset state, causing it to restart and run its primary bootloader, entering the UART serial port download state, and outputting "Waiting for UART download" in the serial port log. When the target microcontroller detects the "Waiting for UART download" output in the serial port log, it immediately sends the secondary bootloader image, pre-stored in the target microcontroller or external SD card, to the DUT prototype via a protocol. After the DUT prototype downloads the secondary bootloader image, it automatically jumps to execute the image, completing the boot process of the DUT prototype.

[0068] In some optional implementations, the testing method for the above-mentioned chip multi-boot mode further includes: Step c1: When the target boot mode is a boot mode based on the first boot medium, control the target selector to switch the signal line of the second boot medium to the target microcontroller side.

[0069] Step c2: When the target boot mode is a boot mode based on the second boot medium, control the target selector to switch the signal line of the first boot medium to the target microcontroller side.

[0070] This step achieves isolation from other memory.

[0071] The chip multi-boot mode testing method provided in this application embodiment achieves precise control of the boot environment of the chip prototype under test by actively isolating non-target boot media before booting the test, thereby ensuring the accuracy, reliability and isolation of the test.

[0072] In some optional implementations, step S4042 above includes: Step d1: If the startup log contains at least one of multiple startup success keywords within a preset time period, then the test result of the chip prototype under test in the target startup mode is determined to be a successful startup. The preset time period is determined based on the target startup mode.

[0073] When the target boot mode is based on the first boot medium, the preset time period is 3-5 seconds after the reset state of the prototype chip under test is released. When the target boot mode is based on the second boot medium, the preset time period is 7-10 seconds after the reset state of the prototype chip under test is released. When the target boot mode is based on the third boot medium, the preset time period is 10-15 seconds after the reset state of the prototype chip under test is released.

[0074] If the test result of the chip prototype under test in the target boot mode is a successful boot, then send "BOOT_SUCCESS" to the host computer.

[0075] The chip multi-boot mode testing method provided in this application determines that the test result of the chip prototype under test in the target boot mode is successful if the boot log includes at least one of multiple boot success keywords within a preset time period. It can automatically shield occasional noise or abnormal BootROM output, ensuring more accurate test results.

[0076] In some optional implementations, step S4042 above includes: Step e1: If the startup log does not contain at least one of the multiple startup success keywords within the preset time period, then the test result of the chip prototype under test in the target startup mode is determined to be a startup failure. The preset time period is determined based on the target startup mode.

[0077] If the test result of the chip prototype under test in the target boot mode is boot failure, then send "BOOT_FAIL" to the host computer.

[0078] If the test result of the chip prototype under test in the target boot mode is a boot failure, record the boot failure timestamp, key log fragments and the current boot mode to facilitate subsequent location and analysis.

[0079] The chip multi-boot mode testing method provided in this application determines the test result of the chip prototype under test as boot failure if the boot log does not include at least one of the multiple boot success keywords within a preset time period, thus ensuring more accurate test results.

[0080] In some optional implementations, step S4042 above includes: Step f1: If any one of the multiple successful startup keywords is matched for the first time in the startup log, and the first match occurs within a preset time period, then the test result of the chip prototype under test in the target startup mode is determined to be a successful startup.

[0081] The first matching time is the moment when any one of the multiple successful startup keywords is first matched in the startup log.

[0082] The chip multi-boot mode testing method provided in this application adopts the "first-match" principle, obtaining the test result as soon as the first successful boot keyword is matched, without waiting for or parsing all log output. This greatly shortens the judgment time of a single test, and significantly improves the overall throughput, especially in batch testing.

[0083] Embodiments of this application provide a testing method for chip multi-boot modes, applied to the aforementioned target microcontroller. Figure 5 This is a flowchart illustrating the testing method for chip multi-boot modes provided in an embodiment of this application, as shown below. Figure 5 As shown, the test method for the multi-boot mode of this chip includes the following steps: Waiting for instructions: Waiting for the host computer to send an instruction to set the boot mode, such as "SET_MODE SPI_FLASH" or "SET_MODE EMMC".

[0084] After receiving the instruction from the host computer to set the startup mode, the target microcontroller first pulls down the reset signal of the prototype chip under test, so that the prototype chip under test is in a reset state.

[0085] The boot mode is determined. If the boot mode is based on either the first boot medium or the second boot medium, and a flashing image command is received from the host computer, a target selector is configured to connect the target microcontroller to the first or second boot medium, updating the original secondary boot image in either medium. The target selector is then configured to connect the prototype chip under test (DUT) to either the first or second boot medium. Based on the boot mode, the level of the DUT's boot pin is adjusted. After waiting 20-50 milliseconds, the reset state of the DUT is released, allowing it to enter the new boot mode.

[0086] When the boot mode is based on the third boot medium, the level of the boot pin of the chip under test prototype is adjusted according to the boot mode. After waiting for 20~50 milliseconds, the reset state of the chip under test prototype is released. The target microcontroller waits for the serial port log to output "Waiting for UART download" and sends the secondary boot program image to the chip under test prototype.

[0087] Listen to the boot log of the target microcontroller: Collect the boot log output from the BootROM or secondary bootloader image of the prototype chip under test through the UART Rx (receive) port.

[0088] Determine if a startup success keyword is matched: Determine if the startup log within a preset time period contains at least one of multiple startup success keywords.

[0089] If a keyword indicating successful startup is matched, the test result is determined to be a successful startup. If no keyword indicating successful startup is matched, the test result is determined to be a failed startup.

[0090] The test results are reported to the host computer.

[0091] Throughout the process, the target microcontroller and the host computer interact via a simple text protocol or a lightweight binary protocol. The host computer script only needs to send instructions such as setting the boot mode and burning the image in sequence. The target microcontroller will drive the hardware step by step according to the process of the multi-boot mode test method described above, and finally send back the test results and some logs. Testers no longer need to manually operate jumpers or repeatedly power off and on. They only need to list multiple boot mode test cases in the host computer script, and the target microcontroller can automatically complete the entire process from controlling the chip under test prototype to enter the reset state, switching signal lines, setting the boot pin, releasing the reset state, to log judgment. When the test script switches to the next test case, the host computer only needs to send commands such as "SET_MODE EMMC" or "SET_MODE UART" to the target microcontroller, and the target microcontroller can continue to execute the test of another boot mode, achieving verification of multiple boot modes with a single power-on.

[0092] The chip multi-boot mode testing method provided in this application supports dynamic switching of boot modes without manual intervention, improving testing efficiency and reliability. The chip prototype can be tested in multiple boot modes after a single power-on. All tests can be performed sequentially on the same development board using the same script after a single power-on, with control complexity residing solely in the target MCU's firmware logic. This method not only significantly reduces the number of power-on / off cycles and manual costs but also greatly improves test repeatability and consistency, meeting the rigid requirements of modern automated chip verification for rapid iteration and multi-scenario coverage.

[0093] The chip multi-boot mode testing method provided in this application combines a host computer script with the target MCU firmware to complete a closed-loop process of image burning, multiple boot mode testing, log monitoring, and result judgment without manual intervention, greatly reducing labor costs. This application's solution relies solely on software control and built-in hardware logic to ensure consistency in each switching and reset operation.

[0094] It should be noted that by making targeted modifications to the configuration file of the target microcontroller (such as the level state of the startup pin corresponding to the startup mode and the list of startup success keywords), the chip multi-boot mode testing method provided in this application embodiment can be applied to chip platforms with different architectures such as ARM, RISC-V, and MIPS.

[0095] Furthermore, once the chip prototype under test enters the mass production stage, the chip multi-boot mode testing method provided in this application can be implemented in Automated Test Equipment (ATE). ATE has large test sockets that can support parallel testing of multiple chips. By utilizing the high-end measurement resources of ATE (oscilloscope, logic analyzer, power analyzer) in collaboration with microcontrollers, an integrated production line solution of "parallel multi-chip boot testing + electrical characteristic measurement + boot log acquisition" can be formed.

[0096] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0097] Embodiments of this application also provide a testing apparatus for chip multi-boot modes, such as... Figure 6 As shown, the test apparatus for the chip's multi-boot mode includes: The receiving module 601 is used to receive the start mode setting command sent by the host computer and control the prototype chip under test to be in a reset state.

[0098] The first determining module 602 is used to determine the target boot mode based on the boot mode setting instruction.

[0099] The first startup module 603 is used to control the target selector to switch the signal line of the first startup medium or the signal line of the second startup medium to the chip under test prototype side when the target startup mode is a startup mode based on the first startup medium or a startup mode based on the second startup medium. Based on the target startup mode, it adjusts the level state of the startup pin of the chip under test prototype, releases the reset state of the chip under test prototype, so that the chip under test prototype restarts, runs the first-level boot program, reads the second-level boot program image from the first startup medium or the second startup medium, and completes the startup of the chip under test prototype based on the second-level boot program image.

[0100] The second determining module 604 is used to determine the test results of the chip prototype under test in the target startup mode based on the startup log of the chip prototype under test.

[0101] In some optional implementations, the above-mentioned test apparatus for multi-boot modes of the chip further includes: The acquisition module is used to acquire the target secondary bootloader image based on the flashing image instruction sent by the host computer if it receives the flashing image instruction.

[0102] The first switching module is used to control the target selector to switch the signal line of the first startup medium or the signal line of the second startup medium to the target microcontroller side.

[0103] The update module is used to update the original secondary boot image in the first boot medium or the second boot medium using the target secondary boot image.

[0104] The second switching module is used to control the target selector to switch the signal line of the first startup medium or the signal line of the second startup medium to the prototype side of the chip under test after the update is completed.

[0105] In some optional implementations, the above-mentioned test apparatus for multi-boot modes of the chip further includes: The second startup module is used to adjust the level state of the startup pin of the chip under test prototype and release the reset state of the chip under test prototype when the target startup mode is a startup mode based on the third startup medium. If the connection between the transmit line of the asynchronous transceiver of the target microcontroller and the receive line of the asynchronous transceiver of the prototype chip under test is normal, the chip under test prototype will restart, run the first-level boot program, receive the second-level boot program image sent by the target microcontroller, and complete the startup of the chip under test prototype based on the second-level boot program image.

[0106] In some optional implementations, the above-mentioned test apparatus for multi-boot modes of the chip further includes: The third switching module is used to control the target selector to switch the signal line of the second boot medium to the target microcontroller side when the target boot mode is a boot mode based on the first boot medium.

[0107] The fourth switching module is used to control the target selector to switch the signal line of the first boot medium to the target microcontroller side when the target boot mode is a boot mode based on the second boot medium.

[0108] In some alternative implementations, the second determining module 604 includes: The acquisition unit is used to collect the startup logs output by the prototype chip under test during the startup process.

[0109] The first determining unit is used to determine the test results of the chip prototype under test in the target boot mode based on multiple boot success keywords and boot logs.

[0110] In some optional implementations, the first determining unit includes: The first determining subunit is used to determine that the test result of the chip prototype under test in the target startup mode is a successful startup if the startup log contains at least one of multiple startup success keywords within a preset time period.

[0111] The preset time period is determined based on the target startup mode.

[0112] In some optional implementations, the first determining unit includes: The second determining subunit is used to determine that the test result of the chip prototype under test in the target startup mode is a startup failure if the startup log does not include at least one of the multiple startup success keywords within a preset time period; the preset time period is determined based on the target startup mode.

[0113] For a description of the features in the embodiment corresponding to the test device for chip multi-boot mode, please refer to the relevant description in the embodiment corresponding to the test method for chip multi-boot mode, which will not be repeated here.

[0114] Embodiments of this application also provide an electronic device, such as... Figure 7 As shown, it includes a processor 701 and a memory 702, in which a computer program is stored. The processor 701 is configured to run the computer program to perform the steps in the test method embodiment of any of the above-described chip multi-boot modes.

[0115] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in the test method embodiments of any of the above-described chip multi-boot modes when running.

[0116] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0117] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in the test method embodiments for any of the chip multi-boot modes described above.

[0118] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the test method embodiments of any of the above-described chip multi-boot modes.

[0119] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0120] The foregoing has provided a detailed description of a chip multi-boot mode testing method, apparatus, electronic device, and storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A test method for multiple boot modes of a chip, characterized in that, Applied to target microcontrollers, including: Receive the startup mode setting command sent by the host computer and control the prototype chip under test to be in a reset state; Based on the startup mode setting instructions, the target startup mode is determined; When the target boot mode is a boot mode based on a first boot medium or a boot mode based on a second boot medium, the target selector switches the signal line of the first boot medium or the signal line of the second boot medium to the side of the chip under test prototype. Based on the target boot mode, the level state of the boot pin of the chip under test prototype is adjusted, and the reset state of the chip under test prototype is released so that the chip under test prototype restarts, runs the first-level boot program, reads the second-level boot program image from the first boot medium or the second boot medium, and completes the boot of the chip under test prototype based on the second-level boot program image. Based on the startup logs of the chip prototype under test, the test results of the chip prototype under test in the target startup mode are determined.

2. The method according to claim 1, characterized in that, Before the target selector switches the signal line of the first startup medium or the signal line of the second startup medium to the prototype side of the chip under test, the method further includes: If a flashing image instruction is received from the host computer, the target secondary bootloader image is obtained based on the flashing image instruction. The target selector switches the signal line of the first or second startup medium to the target microcontroller side. The original secondary bootloader image in the first boot medium or the second boot medium is updated using the target secondary bootloader image; After the update is completed, the target selector will switch the signal line of the first startup medium or the signal line of the second startup medium to the prototype side of the chip under test.

3. The method according to claim 1, characterized in that, The transmit line of the asynchronous transceiver of the target microcontroller is connected to the receive line of the asynchronous transceiver of the prototype chip under test. The communication parameters of the asynchronous transceiver of the target microcontroller are set to be the same as the target communication parameters in the first-level bootloader of the chip under test prototype. The method further includes: When the target boot mode is a boot mode based on a third boot medium, if the connection between the transmit line of the asynchronous transceiver of the target microcontroller and the receive line of the asynchronous transceiver of the prototype chip under test is normal, then based on the target boot mode, the level state of the boot pin of the prototype chip under test is adjusted to release the reset state of the prototype chip under test, so that the prototype chip under test restarts, runs the first-level boot program, receives the second-level boot program image sent by the target microcontroller, and completes the boot of the prototype chip under test based on the second-level boot program image.

4. The method according to claim 1, characterized in that, The method further includes: When the target startup mode is a startup mode based on the first startup medium, the target selector switches the signal line of the second startup medium to the target microcontroller side. When the target startup mode is a startup mode based on the second startup medium, the target selector switches the signal line of the first startup medium to the target microcontroller side.

5. The method according to claim 1, characterized in that, The determination of the test results of the chip under test prototype in the target boot mode based on the boot log of the prototype includes: Collect the startup logs output by the prototype chip under test during the startup process; Based on multiple successful startup keywords and the startup log, the test results of the chip prototype under test in the target startup mode are determined.

6. The method according to claim 5, characterized in that, The determination of the test results of the chip prototype under test in the target boot mode based on multiple successful boot keywords and the boot log includes: If the startup log contains at least one of multiple startup success keywords within a preset time period, then the test result of the chip prototype under test in the target startup mode is determined to be a successful startup. The preset time period is determined based on the target startup mode.

7. The method according to claim 5, characterized in that, The determination of the test results of the chip prototype under test in the target boot mode based on multiple successful boot keywords and the boot log includes: If the startup log does not include at least one of the multiple startup success keywords within a preset time period, then the test result of the chip prototype under test in the target startup mode is determined to be a startup failure; the preset time period is determined based on the target startup mode.

8. A testing device for chip multi-boot modes, characterized in that, include: The receiving module is used to receive the start mode setting command sent by the host computer and control the prototype chip under test to be in a reset state. The first determining module is used to determine the target startup mode based on the startup mode setting instruction; The first startup module is configured to, when the target startup mode is a startup mode based on a first startup medium or a startup mode based on a second startup medium, control the target selector to switch the signal line of the first startup medium or the signal line of the second startup medium to the chip under test prototype side, and adjust the level state of the startup pin of the chip under test prototype based on the target startup mode, release the reset state of the chip under test prototype, so that the chip under test prototype restarts, runs the first-level boot program therein, reads the second-level boot program image from the first startup medium or the second startup medium, and completes the startup of the chip under test prototype based on the second-level boot program image; The second determining module is used to determine the test results of the chip prototype under test in the target startup mode based on the startup log of the chip prototype under test.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the test method for the chip multi-boot mode as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the test method for the chip multi-boot mode as described in any one of claims 1 to 7.

Images