System-on-chip fault localization method, system-on-chip, device and storage medium
Patent Information
- Application Number
- CN202111662394.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-12-30
- Publication Date
- 2026-08-28
- Estimated Expiration
- 2041-12-30
AI Technical Summary
[0004]本申请实施例提供了一种片上系统的故障定位方法、片上系统、设备及存储介质,以解决现有技术中片上系统在进行性能测试及故障定位时面对更加复杂的测试环境及更高的测试性能需求,现有的测试方式故障定位不准确,测试效率低下的问题
Smart Images

Figure CN116414632B_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of electronic technology, and in particular relates to a fault location method for a system-on-a-chip, a system-on-a-chip, a device, and a storage medium. Background Technology
[0002] System-on-a-Chip (SoC) is a crucial implementation technology in electronic applications and has a wide range of uses within chips. To ensure chip performance, functional debugging and performance testing of the SoC are necessary.
[0003] Traditional methods for troubleshooting system-on-chip (SoC) issues primarily involve using JTAG (Joint Test Action Group) and serial port access to the SoC to eliminate as many functional problems as possible while ensuring performance meets requirements. Common SoCs typically include several processor or controller modules, a bus, and several peripheral modules that communicate via the bus. As SoC functionality expands, the number of modules in each part continues to increase. Furthermore, to test the most complete system possible, as many peripheral modules as possible are added for testing. This results in a more complex testing environment and higher performance requirements for SoC performance testing and fault localization. Existing testing methods suffer from inaccurate fault localization and low testing efficiency. Summary of the Invention
[0004] This application provides a fault location method for a system-on-a-chip (SoC), an SoC, a device, and a storage medium to address the problems in the prior art where existing testing methods suffer from inaccurate fault location and low testing efficiency when facing more complex testing environments and higher testing performance requirements during performance testing and fault location of SoCs.
[0005] A first aspect of this application provides a fault location method for a system-on-a-chip (SoC), applied to a fault location unit of the SoC. The fault location unit is disposed within the SoC and connected to a first monitor and a second monitor. The first monitor is connected to a connection line between a master device and a bus, and the second monitor is connected to a connection line between a slave device and the bus. The fault location method includes:
[0006] When a system anomaly is detected in the on-chip system, the abnormal state of the target component is determined;
[0007] Based on the abnormal state of the target component, device operation data associated with the target component is collected; the device operation data includes: first interaction data between the master device and the bus obtained from the first monitor, second interaction data between the slave device and the bus obtained from the second monitor, and / or, device static data corresponding to the master device or the slave device;
[0008] Based on the equipment's operating data, fault location is performed.
[0009] A second aspect of this application provides a system-on-a-chip, including: a fault location unit, the fault location unit being connected to a first monitor and a second monitor, the first monitor being connected to a connection line between a master device and a bus, and the second monitor being connected to a connection line between a slave device and the bus; the fault location unit includes:
[0010] The state determination module is used to determine the abnormal state of the target component when a system abnormality is detected in the on-chip system.
[0011] The data acquisition module is used to collect device operation data associated with the target component based on the abnormal state of the target component; the device operation data includes: first interaction data between the master device and the bus obtained from the first monitor, second interaction data between the slave device and the bus obtained from the second monitor, and / or, device static data corresponding to the master device or the slave device;
[0012] The fault location module is used to locate faults based on the equipment's operating data.
[0013] A third aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described in the first aspect.
[0014] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.
[0015] The fifth aspect of this application provides a computer program product that, when run on a terminal, causes the terminal to perform the steps of the method described in the first aspect.
[0016] As can be seen from the above, in this embodiment of the application, by setting a fault location unit in the on-chip system, when a system abnormality is detected in the on-chip system, the abnormal state of the target component is determined. Based on the abnormal state of the target component, the fault location unit collects device operation data such as device interaction data and device static data associated with the target component through the structural relationship between the on-chip system and other components. Then, based on the device operation data, fault location is performed. This scheme can select to acquire different data based on actual fault location requirements. By using the interaction data between the master device and the bus, the interaction data between the slave device and the bus, and the device static data corresponding to the master device or slave device, the cause of the fault is analyzed from the aspects of device interaction process, device operation process, and device operation configuration, so as to achieve accurate location of the fault node, meet the fault location requirements under different abnormal states of components, and improve the fault location accuracy and system testing efficiency under complex test environments and higher test performance requirements. Attached Figure Description
[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art 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.
[0018] Figure 1 This is a flowchart of a fault location method for a system-on-a-chip provided in an embodiment of this application. Figure 1 ;
[0019] Figure 2 This is a structural diagram showing the relationship between various components in the on-chip system provided in the embodiments of this application;
[0020] Figure 3 This is a flowchart of a fault location method for a system-on-a-chip provided in an embodiment of this application. Figure 2 ;
[0021] Figure 4 This is a module structure diagram of the system-on-a-chip provided in the embodiments of this application;
[0022] Figure 5 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation
[0023] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.
[0024] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.
[0025] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.
[0026] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.
[0027] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrases "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."
[0028] In specific implementations, the terminals described in the embodiments of this application include, but are not limited to, other portable devices such as mobile phones, laptop computers, or tablet computers with touch-sensitive surfaces (e.g., touchscreen displays and / or touchpads). It should also be understood that in some embodiments, the device is not a portable communication device, but a desktop computer with touch-sensitive surfaces (e.g., touchscreen displays and / or touchpads).
[0029] The following discussion describes terminals that include displays and touch-sensitive surfaces. However, it should be understood that terminals may include one or more other physical user interface devices such as physical keyboards, mice, and / or joysticks.
[0030] The terminal supports a variety of applications, such as one or more of the following: drawing applications, presentation applications, word processing applications, website creation applications, disc burning applications, spreadsheet applications, game applications, telephone applications, video conferencing applications, email applications, instant messaging applications, exercise support applications, photo management applications, digital camera applications, digital camcorder applications, web browsing applications, digital music player applications, and / or digital video player applications.
[0031] Various applications that can run on a terminal can use at least one common physical user interface device, such as a touch-sensitive surface. One or more functions of the touch-sensitive surface and the corresponding information displayed on the terminal can be adjusted and / or changed between and / or within applications. In this way, the terminal's common physical architecture (e.g., the touch-sensitive surface) can support various applications with user interfaces that are intuitive and transparent to the user.
[0032] It should be understood that the sequence number of each step in this embodiment does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of this application embodiment.
[0033] To illustrate the technical solution described in this application, specific embodiments are provided below.
[0034] See Figure 1 , Figure 1 This is a flowchart of a fault location method for a system-on-a-chip provided in an embodiment of this application. Figure 1 .like Figure 1 As shown, a fault location method for an on-chip system includes the following steps:
[0035] When a system anomaly is detected in the on-chip system, the abnormal state of the target component is determined.
[0036] Based on the abnormal state of the target component, device operation data associated with the target component is collected; the device operation data includes: first interaction data between the master device and the bus obtained from the first monitor, second interaction data between the slave device and the bus obtained from the second monitor, and / or, device static data corresponding to the master device or slave device;
[0037] Fault location is performed based on equipment operation data.
[0038] Before elaborating on the specific implementation of this method, we will first explain the application objects of the above-mentioned on-chip system fault location method.
[0039] The above-mentioned system-on-a-chip fault location method is applied to the system-on-a-chip fault location unit, which is set in the system-on-a-chip. The fault location unit is connected to a first monitor and a second monitor, wherein the first monitor is connected to the connection line between the master device and the bus, and the second monitor is connected to the connection line between the slave device and the bus.
[0040] Specifically, the on-chip system includes multiple master devices and multiple slave devices, which are connected via a bus to achieve data transmission.
[0041] At any given time, the bus can only be occupied by one master device and one slave device. If multiple master devices need to request data from the same slave device, the multiple master devices can only wait in sequence to obtain the right to use the bus and read data from the slave device in multiple separate transactions. The slave device will then process the requests from the multiple master devices accordingly. Conversely, when a slave device requests data from a master device, the processing procedure is the same.
[0042] In one example, combined Figure 2 As shown, the System-on-Chip (SoC) includes a master device M0, a slave device S0, and an NOC bus. In addition, a djtag box is added to the SoC. This djtag box is a fault location unit set in the SoC to acquire interactive data.
[0043] Both the master device M0 and the slave device S0 are connected to the NOC bus. A first monitor is connected to the connection line between the master device M0 and the NOC bus, and a second monitor is connected to the connection line between the master device M0 and the NOC bus. Both monitors are connected to the djtag box.
[0044] Peripheral modules belong to the Slave class, i.e., slave device modules. These could be DMA (Direct Memory Access) modules, or USB (Universal Serial Bus), MIPI (Mobile Industry Processor Interface), SDIO (Secure Digital Input and Output), UART (Universal Asynchronous Receiver / Transmitter), and other similar peripheral modules. Different peripheral modules correspond to independent functional circuit modules (IPs in the diagram). The fault location unit (djtag box) in the on-chip system can acquire static data from these functional modules.
[0045] The fault location unit in the system-on-a-chip is also used to connect with an external open-source debugger (DAP). The DAP integrates a JTAG application chip (JTAG-AP) and is equipped with a JTAG debug interface (JTAG prot). Through the JTAG debug interface, software developers can easily control the operation of components in the system-on-a-chip through the DAP and perform code debugging conveniently and quickly.
[0046] In order to analyze which transmission caused the system anomaly and to provide users with a way to capture data interaction information of interest on the bus, the monitor can be set up to capture the idle / suspended state of the bus and the interaction data of specified objects, so as to realize fault location and analysis.
[0047] In the actual implementation process, users can find the module to be debugged in advance, pre-configure the signal group to be viewed, and when a system abnormality is detected, they can collect the equipment operation data associated with the target component according to the configuration information.
[0048] Based on this, a fault location method for on-chip systems is proposed. The implementation process of each step in this fault location method is as follows:
[0049] Step 101: When a system anomaly is detected in the on-chip system, determine the abnormal state of the target component.
[0050] The detection of system anomalies in the on-chip system can be carried out by the fault location unit without the intervention of an external debugger. Specifically, the fault location unit can periodically access the registers corresponding to different components in the on-chip system to obtain component operation data and thus obtain whether the system has an anomaly and the abnormal state of the target component.
[0051] Alternatively, when an external debugger is involved, the detection of whether a system anomaly has occurred in the on-chip system can be achieved through an external DAP connected to the on-chip system. When the anomaly detection result output by the DAP is obtained, it is determined that a system anomaly has occurred in the on-chip system.
[0052] In this case, a diagnostic interface is set on the system-on-chip (SoC) to connect to an external DAP debugger. The SoC is then used to perform functional tests and detect anomalies through the external debugger.
[0053] Therefore, the fault location unit in the system-on-a-chip needs to be connected to this diagnostic interface to obtain the diagnostic results. Correspondingly, when a system anomaly is detected in the system-on-a-chip, the abnormal state of the target component is determined, including:
[0054] Establish a communication connection with the connected debugger through the diagnostic interface;
[0055] Obtain the system anomaly diagnosis results output by the debugger after debugging the on-chip system, and determine the abnormal state of the target component in the on-chip system based on the system anomaly diagnosis results.
[0056] During this process, the system anomaly diagnosis results will indicate the target component involved in the anomaly in the on-chip system. The fault location unit can obtain the abnormal state of the component from the on-chip system based on the target component.
[0057] For example, if the system anomaly diagnosis result indicates that the request sent by the master device to the main line cannot be responded to within the valid time, then the abnormal state of the bus can be obtained. This abnormal state could be, for example, a bus hangup or a bus interference state. The abnormal state can be obtained, for example, by reading the bus operation data stored in the bus register and parsing it.
[0058] Alternatively, the system anomaly diagnosis results may simultaneously indicate the target component involved in the anomaly in the on-chip system and the abnormal state of that component. The fault location unit can directly obtain the abnormal state of the target component based on the system anomaly diagnosis results output by the external diagnostic tool.
[0059] The method for determining the system anomaly and the abnormal state of the target component in the on-chip system can be determined based on actual needs and the specific diagnostic output of the external diagnostic tool, providing more diverse implementation means.
[0060] Step 102: Based on the abnormal state of the target component, collect the equipment operation data associated with the target component.
[0061] The device operation data includes: first interaction data between the master device and the bus obtained from the first monitor, second interaction data between the slave device and the bus obtained from the second monitor, and / or, device static data corresponding to the master device or slave device.
[0062] In this embodiment of the method, after determining that the system is abnormal, the next step is to implement a further fault location function in order to find the fault node that caused the abnormality.
[0063] Therefore, it is necessary to collect equipment operation data associated with the target component based on the abnormal state of the target component. Specifically, the equipment operation data associated with the target component includes: the target component's own equipment operation data, and the equipment operation data of other components that have data interaction relationships with the target component.
[0064] The equipment operation data can include interactive data generated during the interaction between devices or static data of the devices. Based on the actual fault location requirements, different data can be selected for acquisition to meet the fault location requirements of different components under abnormal conditions.
[0065] Step 103: Based on the equipment's operating data, locate the fault.
[0066] After obtaining the device operation data, the interaction data between the master device and the bus, the interaction data between the slave device and the bus, and the static data of the master or slave device can be used to analyze the cause of the fault from the aspects of device interaction process, device operation process, and device operation configuration, so as to achieve accurate location of the fault node and improve the accuracy of fault location and system testing efficiency under complex testing environment and higher testing performance requirements.
[0067] In one specific implementation, the process of collecting equipment operation data associated with the target component based on the abnormal state of the target component includes:
[0068] When the abnormal state of the target component indicates that the bus is dead, obtain the abnormal trigger time of the bus dead state.
[0069] The device operation data is obtained by capturing the interaction data between the device and the bus at the moment of abnormal triggering by the target monitor.
[0070] Among them, the target monitor is the monitor that captures interactive data at the time of the exception triggering, which is the first monitor and the second monitor.
[0071] The time of the exception trigger can be obtained by parsing the trace file to obtain the recorded timestamped running trajectory data, and then obtaining the time when the bus was stuck, which is the exception trigger time of the bus stuck state. Alternatively, it can be obtained by parsing the system exception diagnosis results output by an external debugger to obtain the exception trigger time corresponding to the abnormal state of the target component.
[0072] Furthermore, when the bus hangs, based on the abnormal trigger time of the bus hang state, the monitor connected to the fault location unit determines which master device issued an access operation to the bus and caused the abnormality, or which slave device was accessed and caused the abnormality.
[0073] Therefore, it is necessary to use the monitor that captures interactive data at critical moments as the target monitor, and extract the interactive data between the device and the bus captured by the target monitor at those critical moments, so as to locate the fault based on the operating data of these devices.
[0074] Correspondingly, this fault location based on equipment operating data includes:
[0075] Determine the target device to which the device operation data captured by the target monitor at the time of abnormal triggering belongs from the master device and slave devices; generate a fault location result containing descriptive information of the target device and its operation data.
[0076] This process requires identifying which device caused the bus failure based on the interaction data between the device and the bus captured by the target monitor at the moment the anomaly was triggered.
[0077] Specifically, when the target monitor is the first monitor, the target master device to which the device operation data captured by the first monitor at the time of abnormal triggering is determined from the master device, and a fault location result containing descriptive information of the target master device and the device operation data is generated.
[0078] When the target monitor is the second monitor, the target slave device to which the device operation data captured by the second monitor at the time of the abnormal trigger is determined from multiple slave devices, and a fault location result containing descriptive information of the target slave device and the device operation data is generated.
[0079] After identifying the target device from the master and slave devices, the device causing the bus fault is determined to be the target device. The device operation data corresponding to the time the bus fault occurred is the interaction data between the target device and the bus at that time. Finally, the fault location result containing the interaction data and the description information of the target device is obtained, thus realizing fault location.
[0080] Furthermore, in another specific embodiment, the main device includes a processor that, based on the abnormal state of the target component, collects device operation data associated with the target component, including:
[0081] When the abnormal state of the target component indicates that the processor is in a dead state, determine whether the bus is dead;
[0082] Once it is confirmed that the bus is not stuck, the device's static data is collected from the processor to obtain the device's operational data.
[0083] In specific applications, the processor can be a CPU (central processing unit), a DSP (digital signal processor), or a GPU (graphics processing unit).
[0084] When the master device contains a processor, if the processor is in a hung abnormal state, the status of the bus is checked to determine which data to use for fault localization. If the processor is hung but the bus is not, it means the processor's hung state is unrelated to the bus; in this case, the processor's own static data needs to be obtained to locate the cause of the fault.
[0085] Specifically, equipment static data refers to data that is primarily used for control or reference during operation.
[0086] The collected static data from the equipment may specifically include the equipment's final words, program technical values, etc.
[0087] When the bus is not dead but the processor is dead, access the last words register and the processor's program counter (PC) to obtain the device's last words and program counter values, and locate which operation caused the processor to hang.
[0088] The device's dying message is the abnormal information recorded when the device malfunctions. The program counter (PC) stores the address of the memory location for the next instruction. When executing an instruction, the instruction is first fetched from memory into the instruction register based on the instruction address stored in the PC; this process is called "instruction fetch." Simultaneously, the address in the PC is either automatically incremented by 1 or the address of the next instruction is given by the jump pointer. Therefore, by extracting static data such as the device's dying message or the program counter value, the specific cause of the processor hang can be accurately located, improving the accuracy of fault location at a deeper level.
[0089] Specifically, the bus status can be obtained by extracting bus status data from the bus register or by obtaining bus status information from the system anomaly diagnostic results output by an external debugger.
[0090] Correspondingly, based on equipment operation data, fault location is performed, including:
[0091] Based on device operation data, trace the instruction execution path before the processor enters a hangup state, and determine the fault occurrence node based on the instruction execution results of the instruction execution path;
[0092] Generate fault location results that include the fault-causing node and the command execution results.
[0093] The instruction execution path specifically refers to the directory list where the operating system searches for local executable files. Specifically, based on static data such as the device's dying message and program technical values, the instruction execution path before the processor entered a hang state can be traced. Then, based on the instruction execution results along this path, the fault location can be determined, pinpointing which processing operation caused the processor to hang.
[0094] Specifically, when a processor is processing a task, if the task corresponds to a multi-threaded business process, since the smallest unit consuming processor resources is actually a thread, the processor exception must be caused by one or more threads consuming excessive processor resources. You can check the percentage of processor resources used by each thread within the process using commands, and you can also see the call stack of each thread. Find the thread that has been identified as consuming the most processor resources, and then find its corresponding call stack. This process makes it easy to see at which step of the processing logic caused the processor exception. Then, use the `trace -p tid` command to trace the thread's call process to pinpoint the corresponding code, achieving accurate fault location. Subsequently, you can fix the bug and resolve the problem.
[0095] In this embodiment, a fault location unit set in the system-on-a-chip (SoC) determines the abnormal state of a target component when a system anomaly is detected. Based on the abnormal state of the target component, and through the structural relationship between the fault location unit and other components in the SoC, it collects device operation data such as device interaction data and device static data associated with the target component. Then, based on the device operation data, fault location is performed. This solution can select to acquire different data based on actual fault location requirements. By utilizing information such as the interaction data between the master device and the bus, the interaction data between the slave device and the bus, and the device static data corresponding to the master or slave device, the cause of the fault can be analyzed from aspects such as the device interaction process, the device operation process, and the device operation configuration. This achieves accurate location of the fault node, meets the fault location requirements under different component abnormal states, and improves the fault location accuracy and system testing efficiency under complex testing environments and higher testing performance requirements.
[0096] This application also provides different implementations of the fault location method for a system-on-a-chip.
[0097] The fault location method of the system-on-a-chip is applied to the fault location unit of the system-on-a-chip. The fault location unit is set in the system-on-a-chip and is connected to a first monitor and a second monitor. The first monitor is connected to the connection line between the master device and the bus, and the second monitor is connected to the connection line between the slave device and the bus.
[0098] The functionality of the fault location unit and the structural relationships between the various components included in the on-chip system have been described in detail in the foregoing embodiments, and will not be repeated here.
[0099] Specifically, in the embodiments of this application, see Figure 3 , Figure 3 This is a flowchart of a fault location method for a system-on-a-chip provided in an embodiment of this application. Figure 2 .like Figure 3 As shown, a fault location method for an on-chip system includes the following steps:
[0100] Step 301: When a system anomaly is detected in the on-chip system, determine the abnormal state of the target component.
[0101] The implementation process of this step is the same as that of step 101 in the aforementioned embodiments, and will not be repeated here.
[0102] Step 302: Based on the abnormal state of the target component, collect the equipment operation data associated with the target component.
[0103] The device operation data includes: first interaction data between the master device and the bus obtained from the first monitor, second interaction data between the slave device and the bus obtained from the second monitor, and / or, device static data corresponding to the master device or slave device.
[0104] The implementation process of this step is the same as that of step 102 in the aforementioned embodiments, and will not be repeated here.
[0105] Step 303: After resetting the on-chip system, the data of the dying words generated in the on-chip system is parsed to obtain the fault point in the on-chip system.
[0106] The static data of this device includes: last words of the dying.
[0107] In the fault location process of this implementation, the dying words information at key locations is added. In some cases where the external debugger cannot be accessed, the dying words information can be checked after the system restarts abnormally to help locate the problem.
[0108] The Last Words register is a register that records abnormal states. When a chip malfunctions and triggers the gate to reset the system, the hardware records signals from critical components such as the bus and processor. The data in the Last Words register is not cleared during the reset, and the recorded signal content can be read from the Last Words register to analyze system problems and locate faults.
[0109] The above processing procedure, based on the user-configured fault location unit, is combined with the functions of an external debugger. When a fault is detected, the fault location unit obtains the intercepted interaction data between the master device and the bus, the interaction data between the slave device and the bus, and the static data corresponding to the master or slave device, according to the debugging logic. The cause of the fault is analyzed from aspects such as the device interaction process, the device operation process, and the device operation configuration, so as to achieve accurate location of the fault node, meet the fault location requirements under different abnormal conditions of components, and improve the fault location accuracy and system testing efficiency under complex testing environments and higher testing performance requirements.
[0110] Further, see Figure 4 , Figure 4 This is a module structure diagram of the system-on-a-chip provided in the embodiments of this application. For ease of explanation, only the parts related to the embodiments of this application are shown.
[0111] The on-chip system 4 includes: fault location unit 400.
[0112] Among them, reference Figure 2 The fault location unit djtag box is connected to a first monitor and a second monitor. The first monitor is connected to the connection line between the master device and the bus, and the second monitor is connected to the connection line between the slave device and the bus.
[0113] Furthermore, combined Figure 4 As shown, the fault location unit 400 includes:
[0114] The state determination module 401 is used to determine the abnormal state of the target component when a system abnormality is detected in the on-chip system.
[0115] The data acquisition module 402 is used to collect device operation data associated with the target component based on the abnormal state of the target component; the device operation data includes: first interaction data between the master device and the bus obtained from the first monitor, second interaction data between the slave device and the bus obtained from the second monitor, and / or, device static data corresponding to the master device or the slave device;
[0116] The fault location module 403 is used to locate faults based on the equipment's operating data.
[0117] The fault location unit is connected to the diagnostic interface; the status determination module 401 is specifically used for:
[0118] A communication connection is established with the connected debugger through the diagnostic interface;
[0119] The system anomaly diagnosis results output by the debugger after debugging the system on-chip are obtained, and the abnormal state of the target component in the system on-chip is determined based on the system anomaly diagnosis results.
[0120] Specifically, the data acquisition module 402 is used for:
[0121] When the abnormal state of the target component is indicated as bus dead state, obtain the abnormal trigger time of the bus dead state;
[0122] The device operation data is obtained by capturing the interaction data between the device and the bus at the time of the abnormality triggering by the target monitor; wherein, the target monitor is the monitor that captures the interaction data at the time of the abnormality triggering between the first monitor and the second monitor.
[0123] Correspondingly, the fault location module 403 is specifically used for:
[0124] The target device to which the device operation data captured by the target monitor at the time of the abnormal triggering is to be determined is determined from the master device and the slave device;
[0125] Generate a fault location result that includes descriptive information about the target device and its operating data.
[0126] The main device includes a processor, and the data acquisition module 402 is specifically used for:
[0127] When the abnormal state of the target component indicates that the processor is in a dead state, determine whether the bus is dead;
[0128] When it is determined that the bus is not suspended, the device static data of the processor is collected to obtain the device operating data.
[0129] Correspondingly, the fault location module 403 is specifically used for:
[0130] Based on the device's operating data, the instruction execution path before the processor entered the hangup state is traced, and the fault occurrence node is determined based on the instruction execution results of the instruction execution path.
[0131] Generate fault location results that include the fault-causing node and the instruction execution results.
[0132] The static data of the device includes: last words data; the fault location module 403 is specifically used for:
[0133] After resetting the system-on-a-chip, the data of the dying words generated in the system-on-a-chip is parsed to obtain the fault point in the system-on-a-chip.
[0134] The on-chip system provided in this application can implement all the processes of the above-described on-chip system fault location method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.
[0135] Figure 5 This is a structural diagram of an electronic device provided in an embodiment of this application. As shown in the figure, the electronic device 5 of this embodiment includes: at least one processor 50 ( Figure 5 (Only one is shown in the diagram), memory 51, and computer program 52 stored in said memory 51 and executable on said at least one processor 50, wherein said processor 50 executes said computer program 52 to implement the steps in any of the above method embodiments.
[0136] The electronic device 5 can be a desktop computer, laptop, handheld computer, cloud server, or other computing device. The electronic device 5 may include, but is not limited to, a processor 50 and a memory 51. Those skilled in the art will understand that... Figure 5 This is merely an example of electronic device 5 and does not constitute a limitation on electronic device 5. It may include more or fewer components than shown, or combine certain components, or different components. For example, the electronic device may also include input / output devices, network access devices, buses, etc.
[0137] The processor 50 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.
[0138] The memory 51 can be an internal storage unit of the electronic device 5, such as a hard disk or memory. The memory 51 can also be an external storage device of the electronic device 5, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 51 can include both internal and external storage units of the electronic device 5. The memory 51 is used to store the computer program and other programs and data required by the electronic device. The memory 51 can also be used to temporarily store data that has been output or will be output.
[0139] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0140] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0141] Those skilled in the art will 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, or a combination of computer software and electronic hardware. 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.
[0142] In the embodiments provided in this application, it should be understood that the disclosed devices / terminals and methods can be implemented in other ways. For example, the device / terminal embodiments described above are merely illustrative. For instance, the division of modules or units 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 displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.
[0143] The units described 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.
[0144] 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.
[0145] If the integrated module / 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, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.
[0146] The methods described in this application can be implemented in whole or in part by a computer program product. When the computer program product is run on a terminal, the terminal executes the steps in the various method embodiments described above.
[0147] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.
Claims
1. A fault location method for a system-on-a-chip, characterized in that, A fault location unit for a system-on-a-chip (SoC) is provided in the SoC. The fault location unit is connected to a first monitor and a second monitor. The first monitor is connected to the connection line between the master device and the bus, and the second monitor is connected to the connection line between the slave device and the bus. The fault location method includes: When a system anomaly is detected in the on-chip system, the abnormal state of the target component is determined; Based on the abnormal state of the target component, device operation data associated with the target component is collected; the abnormal state of the target component includes a processor hangup state or a bus hangup state; the device operation data includes: first interaction data between the master device and the bus obtained from the first monitor, second interaction data between the slave device and the bus obtained from the second monitor, and / or, device static data corresponding to the master device or the slave device, the device static data including last words data and / or program counter value, the last words data and program counter value are used to locate the target operation that caused the processor hangup; the first interaction data and the second interaction data are used to locate the access operation that caused the bus hangup; Based on the equipment's operating data, fault location is performed.
2. The method according to claim 1, characterized in that, The fault location unit is connected to the diagnostic interface; when a system anomaly is detected in the on-chip system, determining the abnormal state of the target component includes: A communication connection is established with the connected debugger through the diagnostic interface; The system anomaly diagnosis results output by the debugger after debugging the system on-chip are obtained, and the abnormal state of the target component in the system on-chip is determined based on the system anomaly diagnosis results.
3. The method according to claim 1, characterized in that, The process of collecting equipment operation data associated with the target component based on its abnormal state includes: When the abnormal state of the target component is indicated as bus dead state, obtain the abnormal trigger time of the bus dead state; The device operation data is obtained by capturing the interaction data between the device and the bus at the time of the abnormality triggering by the target monitor; wherein, the target monitor is the monitor that captures the interaction data at the time of the abnormality triggering between the first monitor and the second monitor.
4. The method according to claim 3, characterized in that, The fault location based on the equipment operating data includes: The target device to which the device operation data captured by the target monitor at the time of the abnormal triggering is to be determined is determined from the master device and the slave device; Generate a fault location result that includes descriptive information about the target device and its operating data.
5. The method according to claim 1, characterized in that, The main device includes a processor, and the acquisition of device operation data associated with the target component based on the abnormal state of the target component includes: When the abnormal state of the target component indicates that the processor is in a dead state, determine whether the bus is dead; When it is determined that the bus is not suspended, the device static data of the processor is collected to obtain the device operating data.
6. The method according to claim 5, characterized in that, The fault location based on the equipment operating data includes: Based on the device's operating data, the instruction execution path before the processor entered the hangup state is traced, and the fault occurrence node is determined based on the instruction execution results of the instruction execution path. Generate fault location results that include the fault-causing node and the instruction execution results.
7. The method according to claim 1, characterized in that, The static data of the equipment includes: last words of a dying person; the fault location based on the equipment operating data includes: After resetting the system-on-a-chip, the data of the dying words generated in the system-on-a-chip is parsed to obtain the fault point in the system-on-a-chip.
8. A system-on-a-chip, characterized in that, include: A fault location unit is provided, which is connected to a first monitor and a second monitor. The first monitor is connected to the connection line between the master device and the bus, and the second monitor is connected to the connection line between the slave device and the bus. The fault location unit includes: The state determination module is used to determine the abnormal state of the target component when a system abnormality is detected in the on-chip system. The data acquisition module is used to collect device operation data associated with the target component based on the abnormal state of the target component; the abnormal state of the target component includes a processor hangup state or a bus hangup state; the device operation data includes: first interaction data between the master device and the bus obtained from the first monitor, second interaction data between the slave device and the bus obtained from the second monitor, and / or, device static data corresponding to the master device or the slave device; the device static data includes terminal message data and / or program counter value, the terminal message data and program counter value are used to locate the target operation that caused the processor hangup; the first interaction data and the second interaction data are used to locate the access operation that caused the bus hangup; The fault location module is used to locate faults based on the equipment's operating data.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in 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 a processor, it implements the steps of the method as described in any one of claims 1 to 7.
Citation Information
Patent Citations
Fault diagnosis method and device for data acquisition system
CN111007452A
Proxy Responder for Handling Anomalies in a Hardware System
US20130262918A1