Debugging method and device and electronic equipment

Abstract

The invention discloses a debugging method and device and electronic equipment, the debugging method is applied to a chip comprising a plurality of different processor cores, the processor cores and hardware resources corresponding to the processor cores are configured to be corresponding system domains, operation systems are configured to run in the system domains respectively, inter-core communication can be carried out among the system domains, and the processor cores and hardware resources corresponding to the processor cores are configured to be corresponding to the system domains. The debugging method comprises the steps that the running state of a first operating system of a first system domain is obtained, and the first system domain is one of the multiple system domains; and switching the first operating system into a debugging service mode under the condition that the first operating system is determined to be abnormal. According to the application, abnormal problems in each system domain of the automobile can be found and solved in time in a development stage, a mass production debugging stage and a real automobile road test stage, and potential safety hazards caused by system faults are avoided.

Description

Technical Field

[0001] This application relates to the field of computer technologies, and particularly to a debugging method, apparatus, and electronic device. Background Art

[0002] In a multi-core heterogeneous system on a chip (SoC), the operating systems of each region are independent of each other. Theoretically, any abnormal situation in a single region will not affect the normal operation of other system regions. However, it may affect the business function logic across regions, but will not affect the debugging work between system regions.

[0003] For example, when a real-time operating system (RTOS) runs in a certain region and a system crash (panic) occurs in that region, generally, error logs are first tried to be checked. If no abnormal problem can be analyzed from the logs, then a hardware debugging tool (such as a DS-5 debugging tool or a Trace32 debugging tool) is connected through a Joint Test Action Group interface (JTAG) for debugging. Since this debugging method depends on hardware debugging tools, it will result in high costs. And for those target circuit boards that do not have the Joint Test Action Group interface (JTAG) led out in advance, the interface often needs to be led out first and the abnormal situation needs to be reproduced to be able to use the hardware tool for debugging, which will seriously affect the analysis efficiency of abnormal situations. Summary of the Invention

[0004] In view of the above technical problems, an object of an embodiment of this application is to provide a debugging method, which is applied to a chip including multiple different processor cores. The processor core and its corresponding hardware resources are configured as corresponding system domains, and operating systems are respectively configured to run within the system domains. Inter-core communication can be performed between multiple system domains. The debugging method includes:

[0005] Obtain the running state of a first operating system of a first system domain, where the first system domain is one of the multiple system domains;

[0006] In the case of determining that the first operating system is abnormal, switch the first operating system to a debugging service mode;

[0007] Based on the debugging service mode, the first system domain sends an operation abnormal signal of the first operating system and a startup state signal of a first program to a second system domain, where the second system domain is a system domain different from the first system domain among the multiple system domains, and the first program is used to debug the first system domain;

[0008] Based on a connection state signal of a second program of the second system domain, determine to debug the first system domain, where the second program is a program used by the second system domain to provide remote debugging for the first system domain.

[0009] As an optional embodiment, a first monitoring module is provided in the system domain. Determining that the first operating system is abnormal includes:

[0010] The first operating system monitors a first abnormal event;

[0011] Or, the first monitoring module monitors a second abnormal event, where the types of the first abnormal event and the second abnormal event are different.

[0012] As an optional embodiment, a second monitoring module is further provided in the system domain. The method further includes:

[0013] Based on the second monitoring module, the second system domain monitors an operation abnormal signal of the first operating system sent by the first system domain;

[0014] Based on the operation abnormal signal, the second system domain monitors a start status signal of the first program in the first system domain.

[0015] As an optional embodiment, the method further includes:

[0016] When the operation abnormal signals of the first operating system sent by the first system domain are monitored by multiple second system domains, determine the running states of the multiple second system domains;

[0017] Based on the running states, determine one of the second system domains as the system domain for debugging the first system domain.

[0018] As an optional embodiment, the method further includes:

[0019] When it is determined that the second program fails to start, restart the first operating system and / or the chip of the first system domain.

[0020] As an optional embodiment, the method further includes:

[0021] When it is determined that the connection between the second system domain and the system domain fails through the second program, restart the first operating system and / or the chip of the first system domain.

[0022] As an optional embodiment, the method further includes:

[0023] When it is determined that the start status signal of the first program in the first system domain monitored by the second system domain is a start failure signal, restart the first operating system and / or the chip of the first system domain.

[0024] The purpose of the embodiment of the present application is to provide a debugging device, which is applied to a chip including multiple different processor cores. The processor cores and their corresponding hardware resources are configured as corresponding system domains, and operating systems are respectively configured to run within the system domains. Inter-core communication can be performed between multiple system domains. The debugging device includes:

[0025] An acquisition module, configured to acquire the running state of the first operating system of the first system domain, where the first system domain is one of the multiple system domains;

[0026] A switching module, configured to switch the first operating system to a debugging service mode when it is determined that the first operating system is abnormal;

[0027] A sending module, configured to send an operation abnormal signal of the first operating system and a startup state signal of the first program to the second system domain based on the debugging service mode. The second system domain is a system domain different from the first system domain among the multiple system domains, and the first program is used to debug the first system domain;

[0028] A debugging module, configured to determine to debug the first system domain based on the connection state signal of the second program of the second system domain, where the second program is a program used by the second system domain to provide remote debugging for the first system domain.

[0029] The purpose of the embodiment of the present application is to provide an electronic device, including a processor and a storage device. An executable program is stored in the storage device, and the storage device executes the executable program to perform the steps of the foregoing method.

[0030] The purpose of the embodiment of the present application is to provide a storage medium, which carries one or more computer programs. When the one or more computer programs are executed by a processor, the steps of the foregoing method are implemented.

[0031] The beneficial effect of the embodiment of the present application lies in:

[0032] The present application can timely discover and solve abnormal problems in each system domain of the vehicle during the development stage, mass production debugging stage, and actual vehicle road test stage, and avoid potential safety hazards caused by system failures. Each system domain is independent and can be coordinated for debugging. An abnormal situation in one system domain will not affect the normal operation of other system domains, and at the same time, the abnormal system domain can be quickly debugged, improving the reliability and stability of the entire vehicle electronic system. Description of the Drawings

[0033] Figure 1 is the flow of the debugging method according to the embodiment of the present application Figure 1 ;

[0034] Figure 2 It is a flowchart of step S20 of the debugging method according to an embodiment of the present application;

[0035] Figure 3 It is a flowchart of step S50 of the debugging method according to an embodiment of the present application;

[0036] Figure 4 It is a flowchart of step S260 of the debugging method according to an embodiment of the present application;

[0037] Figure 5 It is a structural block diagram of a multi-core heterogeneous chip according to an embodiment of the present application;

[0038] Figure 6 It is the flow of the debugging method according to an embodiment of the present application Figure 2 ;

[0039] Figure 7 It is a structural block diagram of the debugging device according to an embodiment of the present application. Detailed implementation manners

[0040] Reference is made herein to the various solutions and features of the present application with reference to the accompanying drawings.

[0041] It should be understood that various modifications can be made to the embodiments applied herein. Therefore, the above description should not be construed as a limitation, but only as an example of the embodiments. Those skilled in the art will think of other modifications within the scope and spirit of the present application.

[0042] The accompanying drawings included in the specification and forming a part of the specification illustrate the embodiments of the present application, and together with the general description of the present application given above and the detailed description of the embodiments given below are used to explain the principles of the present application.

[0043] Through the following description of the preferred forms of the embodiments given as non-limiting examples with reference to the accompanying drawings, these and other features of the present application will become apparent.

[0044] It should also be understood that although the present application has been described with reference to some specific examples, those skilled in the art can surely implement many other equivalent forms of the present application.

[0045] When combined with the accompanying drawings, in view of the following detailed description, the above and other aspects, features and advantages of the present application will become more apparent.

[0046] Specific embodiments of the present application are described hereinafter with reference to the accompanying drawings; however, it should be understood that the embodiments applied for are merely examples of the present application, which may be implemented in a variety of ways. Well-known and / or repeated functions and structures are not described in detail to avoid unnecessary or redundant details that obscure the present application. Therefore, the specific structural and functional details applied for herein are not intended to be limiting, but merely serve as a basis and representative basis for the claims to teach those skilled in the art to use the present application in a variety of ways with substantially any suitable detailed structure.

[0047] This specification may use the phrases "in one embodiment," "in another embodiment," "in yet another embodiment," or "in other embodiments," all of which may refer to one or more of the same or different embodiments according to the present application.

[0048] In a multi-core heterogeneous system, when an exception occurs in any single system domain, troubleshooting often relies on exception logs and hardware debugging tools, but this will face many problems.

[0049] First, the content of debug logs is usually simple, and for some problems, it is difficult to analyze the root cause of the exception from the log.

[0050] Secondly, when using hardware debugging tools such as DS-5 and Trace32, the cost of the tools themselves is relatively high, and the host platform needs to bring out the JTAG debugging interface, which undoubtedly increases the hardware cost.

[0051] Third, for mass-produced host platforms, the JTAG interface is usually not brought out. When a problem occurs, due to the lack of this interface, it is necessary to bring out the interface and re-burn the machine to reproduce the problem. This not only makes it impossible to preserve the abnormal scene, but also makes the problem troubleshooting inefficient.

[0052] Fourth, some host platforms do not allow hardware changes after mass production, which makes it impossible to connect hardware tools for debugging through the JTAG interface.

[0053] Therefore, in response to the above content, an embodiment of the present application provides a debugging method, which is applied to a chip including multiple different processor cores, wherein the processor cores and their corresponding hardware resources are configured as corresponding system domains, and the system domains are respectively configured to run operating systems, and multiple system domains can communicate between cores.

[0054] Among them, a heterogeneous multi-core chip is a chip that contains multiple processor cores of different types. Different processor cores have different architectures, performance, and functions, which can meet complex and diverse computing requirements. For example, the chip used in the electronic control unit (ECU) of a modern car may integrate high-performance ARM Cortex-A series processor cores for running complex in-vehicle infotainment systems, and at the same time include low-power Cortex-M series processor cores for controlling simple but highly real-time tasks such as fuel injection and ignition of the engine.

[0055] A processor core is the core unit in a chip that executes computing tasks and is the basis for data processing and operations in the chip. For example, in the chip of an autonomous driving system in a car, a dedicated processor core may be responsible for processing image data collected by a camera and performing calculations such as object recognition and road detection.

[0056] Hardware resources are various physical devices and components associated with the processor core, providing support for the operation of the processor core. For example, in the engine control system of a car, the hardware resources corresponding to the processor core include sensors (such as temperature sensors, pressure sensors), actuators (such as fuel injectors, throttle valves), and memory for storing programs and data.

[0057] The system domain is a relatively independent operating environment composed of the processor core and its corresponding hardware resources. Each system domain can be configured to run a different operating system to achieve specific functions. For example, in a car, one system domain may be composed of a dedicated processor core and related hardware resources, running a real-time operating system and responsible for vehicle braking control; another system domain runs a general operating system for managing the in-vehicle multimedia system.

[0058] Inter-core communication is the process of data exchange and information transfer between multiple processor cores to achieve collaborative work between different system domains. For example, in the hybrid power system of a car, the system domain for engine control and the system domain for battery management share the operating state of the engine and the battery power information through inter-core communication, so as to optimize power distribution.

[0059] As Figure 1 shown, the debugging method includes:

[0060] S10. Obtain the operating state of the first operating system of the first system domain, where the first system domain is one of the multiple system domains;

[0061] In this embodiment, the first system domain is one of the multiple system domains and is the target system domain that needs to monitor the operating state and perform debugging in this debugging method. For example, in the intelligent driving assistance system of a car, the system domain responsible for adaptive cruise control can be used as the first system domain.

[0062] The first operating system runs within the first system domain and manages the hardware resources and software programs of that system domain. For example, if the first system domain is the vehicle body stability control system of a car, the first operating system may be a real-time embedded operating system to ensure that the system can respond quickly to dynamic changes in the vehicle.

[0063] S20. In the case of determining that the first operating system is abnormal, switch the first operating system to the debug service mode;

[0064] In this embodiment, the debug service mode is a special operating mode that the operating system enters, which can provide debug-related functions and information to facilitate developers to troubleshoot and debug the system. For example, when the in-vehicle navigation system of a car has an abnormality, its operating system is switched to the debug service mode, and at this time, detailed logs, variable values, and other information of the system can be obtained.

[0065] S30. Based on the debug service mode, the first system domain sends an operation abnormality signal of the first operating system and a startup status signal of the first program to the second system domain, where the second system domain is a system domain different from the first system domain among multiple system domains, and the first program is used to debug the first system domain;

[0066] In this embodiment, the operation abnormality signal is a signal sent when the first operating system has an abnormal situation, which is used to indicate that the system has a fault or error. For example, in the electric power steering system of a car, if the motor current is abnormal, the first operating system will send an operation abnormality signal, indicating that there may be a fault in the steering system.

[0067] The first program is a program used to debug the first system domain, which can help developers locate and solve problems in the first system domain. For example, the first program for the car engine control system may be used to check whether parameters such as fuel injection time and ignition advance angle are normal.

[0068] The second system domain is a system domain different from the first system domain among multiple system domains, and is used to remotely debug the first system domain. For example, in a car, the system domain responsible for vehicle diagnosis and management can be used as the second system domain to debug other system domains with specific functions.

[0069] S40. Based on the connection status signal of the second program in the second system domain, determine to debug the first system domain, where the second program is a program used by the second system domain to provide remote debugging for the first system domain.

[0070] In this embodiment, the second program is a program in the second system domain for providing remote debugging to the first system domain. For example, if the second system domain is the central diagnostic system of a vehicle, the second program can establish a communication connection with the first system domain to read the fault codes and operation data of the first system domain for remote debugging.

[0071] The connection status signal is a signal indicating the connection status between the second program and the first program in the first system domain, and is used to determine whether remote debugging can be performed. If the connection between the second program and the first program in the first system domain is normal, the signal shows "Connection successful"; otherwise, it shows "Connection failed".

[0072] When this application is in use, for the first operating system in the first system domain, its operation status information such as CPU usage rate, memory occupancy, and task execution status is obtained through the internal monitoring mechanism of the system.

[0073] Based on the obtained operation status information, it is determined whether the first operating system has an abnormality. The abnormality determination can be based on preset rules, such as too high CPU usage rate, memory overflow, task timeout, etc. If it is determined that there is an abnormality, the first operating system is switched from the normal operation mode to the debugging service mode.

[0074] In the debugging service mode, the first system domain sends the operation abnormality signal of the first operating system and the startup status signal of the first program to the second system domain through inter-core communication. The operation abnormality signal contains information such as the type and occurrence time of the abnormality, and the startup status signal indicates whether the first program has been successfully started.

[0075] After receiving the signal, the second system domain checks the connection status signal of its own second program. If the connection status is normal, it indicates that the second program can establish an effective communication connection with the first program in the first system domain. At this time, it is determined to perform remote debugging on the first system domain.

[0076] For example, an intelligent electric vehicle has multiple system domains, where the first system domain is responsible for the battery management system (BMS), and the second system domain is responsible for the vehicle diagnosis system.

[0077] The first operating system in the first system domain continuously obtains the operation status of the battery management system, including parameters such as the voltage, current, and temperature of the battery, as well as the task execution situation of the BMS operating system.

[0078] When it is monitored that the voltage of a single battery cell in the battery abnormally increases and exceeds the safe range, it is determined that the BMS operating system has an abnormality. The BMS operating system is switched to the debugging service mode.

[0079] The BMS system (the first system domain) sends the operation abnormal signal "abnormal increase in battery cell voltage" and the start status signal of the first program (a program for debugging the BMS) to the vehicle diagnostic system (the second system domain). Assuming that the first program starts successfully, the start status signal shows "debugging program starts successfully".

[0080] After receiving the signal, the vehicle diagnostic system (the second system domain) checks the connection status signal between the second program and the BMS system. If the connection status is normal, it determines to remotely debug the BMS system, reads the detailed data of the BMS system through the second program, and analyzes the reason for the abnormal increase in battery voltage.

[0081] This application can timely detect and solve abnormal problems in each system domain of the vehicle, avoiding potential safety hazards caused by system failures. By means of debugging within the multi-core heterogeneous chip, it is applicable to the development stage, mass production debugging stage, and actual vehicle road test stage.

[0082] Each system domain is independent and can be coordinated for debugging. An abnormality in one system domain will not affect the normal operation of other system domains, and at the same time, the abnormal system domain can be quickly debugged, improving the reliability and stability of the entire vehicle electronic system.

[0083] During the vehicle development process, this debugging method can more conveniently test and debug different system domains, accelerating the development progress and shortening the product launch time. Among them, this debugging method is controlled by a software switch, and the vehicle-mounted system sold to end customers will turn off this debugging function by default.

[0084] As Figure 2 shown, in an embodiment, a first monitoring module is provided within the system domain. The determination of the abnormality of the first operating system includes:

[0085] S201. The first operating system monitors a first abnormal event;

[0086] S202. Or, the first monitoring module monitors a second abnormal event, where the types of the first abnormal event and the second abnormal event are different.

[0087] In this embodiment, the first monitoring module is a module provided within the system domain for monitoring specific system states. In this scenario, the watchdog program can be regarded as the first monitoring module, which can monitor the running state of the system in real time and provide a basis for judging whether the system is abnormal.

[0088] For example, in the system domain of an automotive engine control system, the first monitoring module (similar to the watchdog function) will continuously monitor key parameters such as the engine speed and temperature in real time. If the engine speed suddenly exceeds the normal range, it may trigger corresponding anomaly judgments.

[0089] The first anomaly event is an anomaly detected by the first operating system itself during its operation, usually related to aspects such as the core functions of the operating system, task scheduling, and resource management. When such an anomaly occurs, the system will actively trigger the panic handling process and enter the debug service mode.

[0090] For example, in an in-vehicle infotainment system of a vehicle, when the first operating system is handling the simultaneous operation of multiple applications, due to an error in memory management, the system is unable to properly allocate memory to a newly launched application. The system itself detects this anomaly and triggers a panic, entering the debug service mode. This is a first anomaly event.

[0091] The second anomaly event is an anomaly detected by the first monitoring module (such as a watchdog program), which focuses more on the hardware-related status within the system domain and the stability of system operation. When the monitoring module detects an abnormal state of the system (such as the system getting stuck), it will switch the system to the debug service mode.

[0092] For example, in the system domain of an automotive braking system, the first monitoring module (watchdog program) detects that the processing speed of the brake control unit suddenly slows down, resulting in a system freeze. The watchdog program switches the system to the debug service mode, which belongs to the second anomaly event.

[0093] When this application is in use, it includes the following two situations:

[0094] ① The active mode triggers the debug service mode

[0095] During the normal operation of the first operating system, it continuously monitors its own key functions and resource usage. For example, it checks aspects such as the time of task scheduling, memory allocation and release, and inter-process communication.

[0096] When the first operating system detects that a certain parameter or operation does not conform to the preset rules, it determines that a first anomaly event has occurred. For example, if the execution time of a key task exceeds the set maximum time limit, or a memory allocation fails, etc., it will trigger the panic handling process.

[0097] Once it is determined that the first abnormal event has occurred, immediately enter the panic handling process and actively switch the first operating system to the debug service mode. Subsequently, follow the overall debugging process for signal sending and debugging preparation, such as sending an operation exception signal and the startup status signal of the first program to the second system domain.

[0098] For example, a car has multiple system domains, and one of the system domains is responsible for the automatic air conditioning control of the car.

[0099] During the operation of the first operating system of the automatic air conditioning control system, it is responsible for managing the switching of each air conditioning mode and the temperature adjustment algorithm. When switching to the cooling mode, the operating system needs to allocate memory to store the current temperature settings and sensor data.

[0100] When there are vulnerabilities (i.e., software bugs) in the software of the first operating system, such as logical errors, array out-of-bounds situations, dereferencing of null pointers, etc., these situations may cause abnormal phenomena in the kernel of the first system domain, which triggers the first abnormal event and the system enters the panic handling process.

[0101] At this time, immediately switch the first operating system to the debug service mode, and the automatic air conditioning control system sends an operation exception signal and the startup status signal of the first program for debugging the system to the second system domain responsible for vehicle diagnosis.

[0102] ② Trigger the debug service mode in passive mode

[0103] The first monitoring module (watchdog program) continuously collects data on various hardware devices and system operation status within the system domain, such as the running speed of the processor and the execution progress of tasks.

[0104] The first monitoring module analyzes the collected data according to preset thresholds and rules. When detecting abnormal states such as system jams and response timeouts, it determines that the second abnormal event has occurred. For example, when the system fails to complete a certain key task within the specified time, the watchdog program deems it abnormal.

[0105] The first monitoring module notifies the detected second abnormal event to the system, and the system passively switches the first operating system to the debug service mode. Subsequently, the same debugging process as when the first abnormal event occurs is carried out, including sending relevant signals to the second system domain.

[0106] For example, the first monitoring module (watchdog program) is responsible for monitoring the operation status of the automatic air conditioning control system and obtaining the running speed of the processor and the execution progress of tasks in real time.

[0107] At a certain moment, the watchdog program detects that the speed of the system processing sensor data significantly slows down, resulting in system lag, and determines that a second abnormal event has occurred.

[0108] The watchdog program notifies the system of this abnormal event, and the system switches the first operating system to the debug service mode, and also sends corresponding abnormal signals and startup status signals to the second system domain.

[0109] This application performs abnormal monitoring from both software and hardware levels through the first operating system and the first monitoring module, which can cover more types of abnormal situations and greatly improve the system's ability to detect abnormalities. Once an abnormal event is detected, the system can quickly respond and switch the first operating system to the debug service mode, reducing the impact time of the abnormality on the normal operation of the system.

[0110] As Figure 6 shown, in an embodiment, the first system domain is the server side, and the second system domain is the debug side. When the first system domain sends an operation abnormal signal to the second system domain, after receiving the operation abnormal signal, the second system domain sends a response signal to the first system domain. After the first system domain receives the response signal sent by the second system domain and the response is successful, the communication between the server side and the debug side is normal at this time. Then, the first system domain performs the operation of starting the first program.

[0111] If the response between the first system domain and the second system domain is not successful, at this time, the first system domain resends the operation abnormal signal to the second system domain and cannot perform the operation of starting the first program.

[0112] As Figure 3 shown, in an embodiment, a second monitoring module is further provided within the system domain, and the method further includes:

[0113] S501. Based on the second monitoring module, the second system domain monitors the operation abnormal signal of the first operating system sent by the first system domain;

[0114] S502. Based on the operation abnormal signal, the second system domain monitors the startup status signal of the first program of the first system domain.

[0115] In this embodiment, the second monitoring module is a component that continuously listens for signals from other system domains in the system. It can capture the operation abnormal signal and the startup status signal of the first program sent by the first system domain. It can also provide basic information for selecting a suitable debug service program in the future.

[0116] For example, in the electronic control system of an automobile, if the engine control system is regarded as the first system domain and the vehicle diagnostic system is regarded as the second system domain, the second monitoring module in the second system domain will monitor various signals sent by the engine control system in real time, such as error signals when an abnormality occurs.

[0117] The operation abnormal signal is a signal sent when the first operating system in the first system domain has an abnormality and enters the debug service mode, used to inform other system domains that a fault has occurred. This signal can guide other system domains to start the debug process.

[0118] For example, when there is an abnormal shift jerk in the automatic transmission control system (the first system domain) of an automobile, the system enters the debug mode and sends an operation abnormal signal, such as "shift jerk, fault code 010", to the vehicle diagnostic system (the second system domain).

[0119] The startup status signal of the first program is a signal sent when the first program used to debug the first system domain in the first system domain starts, indicating whether the program starts successfully and the status during the startup process. It can help the second system domain determine whether the debug work can be carried out smoothly.

[0120] For example, in the in-vehicle navigation system (the first system domain) of an automobile, the first program is used to debug the map positioning function. If the startup fails due to damaged map data during startup, a signal of "map debug program startup failed, data damaged" is sent to the vehicle diagnostic system (the second system domain).

[0121] Moreover, in this embodiment, the first program is a debug service program, which is a program that runs after the abnormal system domain enters the debug mode and is used to support the debug work. The debug service program can be a program implemented based on the open-source software gdbstub, and can perform basic debug operations such as viewing registers, function call stacks, and memory data.

[0122] For example, after an abnormality occurs in the intelligent driving assistance system (the first system domain) of an automobile, if a debug service program implemented using gdbstub is used, the values of relevant registers can be viewed to initially troubleshoot the problem.

[0123] The second program is a debug client program, which is a program that runs in the normal system domain and is used to establish a connection with the debug service program in the abnormal system domain and perform remote debugging. The gdb running in the normal system domain can cooperate with the debug service program implemented based on gdbstub.

[0124] For example, when the power control system (the first system domain) of an automobile is abnormal, the vehicle diagnostic system (the second system domain) runs gdb to connect with the debug service program based on gdbstub in the power control system for basic debugging.

[0125] When this application is in use, after the second monitoring module (monitor program) in the second system domain is started, it continuously listens for signals from the first system domain.

[0126] When an exception occurs in the first operating system of the first system domain, whether in the active mode (such as triggering a panic) or the passive mode (such as the watchdog detecting that the system is stuck), it enters the debug service mode and sends an operation exception signal. The second monitoring module in the second system domain captures this signal and passes the information to the second system domain for processing.

[0127] After receiving the operation exception signal, the second system domain sends a response signal to the first system domain, and then starts to monitor the startup status signal of the first program in the first system domain through the second monitoring module. When the first system domain starts the first program, its startup status signal is sent to the second system domain through the communication mechanism, and the second monitoring module obtains and feeds it back to the second system domain.

[0128] Based on the operation exception signal and the startup status signal of the first program, the second system domain determines whether to use the debug service program implemented by gdbstub. If only basic debugging is required, such as viewing registers, etc., the gdbstub-based solution can be selected. That is, the first system domain runs gdbstub to enter the debug mode, and the second system domain runs gdb for remote connection.

[0129] After the connection is successful, corresponding debug operations are performed according to the combination of the debug service program and the client program used. When using the combination of gdbstub and gdb, basic debug operations are performed.

[0130] For example, when a display anomaly occurs in the intelligent cockpit system (the first system domain) of a car, the vehicle diagnostic system (the second system domain) is responsible for debugging.

[0131] During the operation of the intelligent cockpit system, due to an abnormal GPU driver, a panic is triggered, entering the debug service mode and sending an operation exception signal "GPU driver anomaly, screen display is distorted".

[0132] The second monitoring module captures this signal. After the vehicle diagnostic system receives the operation exception signal, it monitors the startup status signal of the first program (used for debugging the display function) in the intelligent cockpit system. If the first program starts successfully, a signal "Display debug program started successfully" is sent to the vehicle diagnostic system.

[0133] If only a preliminary problem investigation is required, the vehicle diagnostic system decides to use a debugging solution based on gdbstub. The intelligent cockpit system runs gdbstub to enter the debugging mode, and the vehicle diagnostic system runs gdb for remote connection. When using the combination of gdbstub and gdb, check the registers and function call stacks of the intelligent cockpit system, and initially judge that the problem may occur during the GPU driver loading process.

[0134] Through the monitoring of the operation abnormal signal and the first program startup status signal by the second monitoring module in this application, the effective cooperation between different system domains is ensured. Select a suitable debugging solution according to the signal situation, making the entire debugging process more efficient and orderly, and improving the reliability and stability of the automotive electronic system.

[0135] In another embodiment, the first program can also be a custom debugging service program, which can meet more advanced debugging requirements, such as viewing the system's interrupt statistics, the processes running on each core, etc. The second program can also be a custom client program, and the client program corresponds to the custom debugging service program, which can obtain richer debugging information.

[0136] If there is a situation that requires advanced debugging requirements, such as viewing the system interrupt statistics, etc., the first system domain runs a custom debugging service program, and the second system domain runs the corresponding custom client program for connection.

[0137] As Figure 4 shown, in one embodiment, the method further includes:

[0138] S601. When the operation abnormal signal of the first operating system sent by the first system domain is monitored in multiple second system domains, determine the running states of the multiple second system domains;

[0139] S602. Based on the running states, determine one of the second system domains as the system domain for debugging the first system domain.

[0140] In this embodiment, in the multi-core heterogeneous chip system of the vehicle, there are multiple second system domains that can remotely debug the first system domain. These system domains have different functions and resources, and they can receive the operation abnormal signals sent by the first system domain and provide debugging services when necessary. For example, in the vehicle, there are multiple system domains such as the central diagnostic system, the telematics system, and the on-vehicle maintenance diagnostic system that can be used as the second system domain.

[0141] The running state refers to the current working conditions of the second system domain, including the system's load condition, resource occupancy rate, whether other important tasks are being executed, etc. The running state will affect whether the second system domain has the ability to debug the first system domain.

[0142] For example, for the second system domain of the central diagnostic system, its operating status may include CPU usage rate, memory occupancy, whether it is diagnosing other subsystems, etc. If the CPU usage rate is too high, it indicates that the system load is large, and it may not be able to debug the first system domain in a timely and effective manner.

[0143] After multiple second system domains all receive the operation exception signal from the first system domain, according to their operating statuses, select the most suitable second system domain to debug the first system domain to ensure the efficiency and accuracy of the debugging work.

[0144] For example, when the engine control system (the first system domain) of a car has an abnormality, the central diagnostic system, the telematics system, and the on-vehicle maintenance diagnostic system all detect the abnormality signal. After evaluation, it is found that the central diagnostic system currently has a low load and has rich engine system diagnostic experience and resources. Therefore, the central diagnostic system is selected as the system domain for debugging the engine control system.

[0145] When this application is in use, the second monitoring modules of multiple second system domains continuously monitor the signals sent by the first system domain. When the first operating system of the first system domain has an abnormality and sends an operation exception signal, multiple second system domains can all receive this signal.

[0146] Each second system domain evaluates its own operating status and collects relevant information, such as CPU usage rate, memory occupancy, task execution situation, etc. Feed back these operating status information to a decision-making module (which can be a specific second system domain or a dedicated management module).

[0147] The decision-making module analyzes and compares according to the operating status information of multiple second system domains received, according to certain rules (such as selecting the system domain with the lightest load and the richest resources). Finally, determine one of the second system domains as the system domain for debugging the first system domain.

[0148] The selected second system domain starts its second program, establishes a communication connection with the first system domain, and starts remote debugging of the first system domain.

[0149] For example, the intelligent network connection system of a car consists of multiple system domains. The first system domain is responsible for the vehicle's autonomous driving function, and there are three second system domains: A (central fault diagnosis system), B (remote technical support system), and C (local maintenance assistance system).

[0150] During the operation of the autonomous driving system (the first system domain), due to abnormal sensor data processing, the first operating system sends an operation exception signal "Sensor data processing failure, unable to accurately identify the road".

[0151] The second monitoring modules of system domains A, B, and C receive the signal, where:

[0152] System domain A: The CPU usage rate is 30%, the memory occupancy rate is 40%, and it is currently performing periodic checks on some conventional systems, but it does not affect the processing of new tasks.

[0153] System domain B: The CPU usage rate is 80%, the memory occupancy rate is 70%, and it is performing a large amount of data transmission with a remote server and processing diagnostic requests from other vehicles.

[0154] System domain C: The CPU usage rate is 20%, the memory occupancy rate is 30%, it is in an idle state, and only performs basic system monitoring.

[0155] The decision-making module analyzes based on the above operating status information and finds that the load of system domain C is the lightest and the resources are the most sufficient. Therefore, system domain C is selected as the system domain for debugging the autonomous driving system.

[0156] System domain C starts its second program, establishes a communication connection with the autonomous driving system (the first system domain), and begins to perform a detailed inspection and debugging on the sensor data processing module, gradually troubleshooting the cause of the fault.

[0157] This application can make full use of its resources and capabilities by selecting the most suitable second system domain for debugging, and avoid prolonging the debugging time or having poor debugging effects due to selecting an inappropriate system domain.

[0158] In one embodiment, the method further includes:

[0159] In the case of determining that the startup of the second program is abnormal, restart the first operating system and / or the chip of the first system domain.

[0160] In this embodiment, the abnormal startup of the second program means that the program used to provide remote debugging to the first system domain in the second system domain fails to start normally during startup, and problems such as program crashes or inability to load necessary library files occur.

[0161] For example, in the electronic control system of an automobile, the second system domain is the vehicle's central diagnostic system, and the second program is responsible for remotely debugging the engine control system (the first system domain). When attempting to start the second program, due to insufficient system memory or damaged relevant driver programs, the program fails to start normally, which is the abnormal startup of the second program.

[0162] When the startup of the second program is abnormal, perform a restart operation on the first operating system running in the first system domain, aiming to try to restore the normal state of the first operating system and eliminate the abnormal scene.

[0163] When the second program fails to start properly or restarting the first operating system cannot resolve the issue of the second program's abnormal startup, the second operating system in the second system domain can perform a restart operation on the entire multi-core heterogeneous chip. This can completely reset the states of each processor core and related hardware resources within the chip, clearing any potential deep-seated hardware or software faults. After the chip restart is completed, the exception context in the first system domain is destroyed, and debugging is not required at this time.

[0164] For example, there is a problem with the debugging between the autonomous driving assistance system (the first system domain) and the central control unit (the second system domain) of a car. The second program fails to start properly. First, attempt to restart the operating system of the autonomous driving assistance system, but the problem persists. At this time, restart the entire control chip.

[0165] When this application is in use, it includes the following situations:

[0166] ① After the second system domain receives the operation exception signal and the startup status signal of the first program from the first system domain, it attempts to start the second program. The second system domain will monitor the startup process of the second program in real-time to determine whether an abnormal startup situation occurs.

[0167] If situations such as program crashes or error messages occur during the startup process, it is determined that the second program fails to start properly. When it is determined that the second program fails to start properly, first attempt to restart the first operating system in the first system domain.

[0168] Send a restart instruction to the first system domain. The first operating system shuts down the running processes according to the normal restart process, re-initializes the system resources, and then starts again.

[0169] Among them, when restarting the first operating system, the second operating system (i.e., the debugging end) returns to re-monitoring the operation exception signal of the first system domain (i.e., the service end). If the first operating system runs normally after restarting, there is no need to continue debugging the first operating system. Because once the first operating system is restarted, the exception context is destroyed, and there is no meaning in continuing debugging.

[0170] ② When the second program fails to start properly, perform a restart operation on the entire chip.

[0171] The second operating system in the second system domain will cut off the power supply of the chip and then power it on again to re-initialize each processor core and hardware resource within the chip. After the chip restart is completed, the exception context in the first system domain is destroyed, and debugging is not required at this time.

[0172] ③ When restarting the first operating system cannot restore the normal operation of the first operating system, at this time, the second operating system can restart the entire SoC chip.

[0173] The second operating system in the second system domain cuts off the power supply of the chip and then powers it on again, re-initializing each processor core and hardware resource within the chip. After the chip restart is complete, the exception context in the first system domain is destroyed, and at this time, debugging is not required.

[0174] For example, an intelligent cockpit system (the first system domain) in a vehicle has a display anomaly, and the vehicle's central diagnostic system (the second system domain) is ready to debug it.

[0175] After receiving the operation anomaly signal from the intelligent cockpit system, the central diagnostic system starts the second program. During the startup process, the second program prompts "Unable to connect to the debug interface of the intelligent cockpit system", indicating an abnormal startup.

[0176] The central diagnostic system sends a restart command to the intelligent cockpit system, and the operating system of the intelligent cockpit system starts to restart. After the restart is complete, the exception context in the first system domain is destroyed, and at this time, debugging is not required.

[0177] If restarting the first operating system at this time fails to solve the problem, the vehicle's central diagnostic system restarts the entire multi-core heterogeneous chip. After the chip restarts, the exception context in the first system domain is destroyed, and at this time, debugging is not required.

[0178] This application re-initializes the system by restarting the first operating system and / or the chip, which can repair system errors to a certain extent, restore the normal operation of the system, protect system resources, and avoid further damage to the system caused by continuous abnormal states. Moreover, after each restart, the exception context is destroyed, avoiding meaningless debugging, saving time and resources, and improving the efficiency of fault handling.

[0179] In one embodiment, the method further includes:

[0180] In the case where it is determined that the second system domain fails to connect to the system domain through the second program, restart the first operating system of the first system domain and / or the chip.

[0181] In this embodiment, when the second program in the second system domain attempts to establish a communication connection with the first program in the first system domain, the connection cannot be successfully established due to various reasons. These reasons may include network failures, communication protocol mismatches, the first system domain being in an abnormal state and unable to respond, etc.

[0182] For example, in a vehicle, the first system domain is the engine control system, and the second system domain is the vehicle diagnostic system. When the second program of the vehicle diagnostic system attempts to establish a connection with the first program of the engine control system for fault diagnosis, the connection fails due to a communication interface failure in the engine control system or an inconsistent communication protocol version used by both parties.

[0183] When a connection failure occurs, a restart operation is performed on the first operating system running in the first system domain. The purpose is to attempt to restore the normal state of the first operating system, eliminate the abnormal scene, and thus no longer require debugging.

[0184] For example, when the in-vehicle navigation system (first system domain) of a car fails to connect during data interaction with the vehicle central control unit (second system domain), the operating system of the in-vehicle navigation system is restarted at this time.

[0185] When a connection failure occurs or restarting the first operating system fails to solve the connection failure problem, the vehicle central control unit restarts the entire multi-core heterogeneous chip. Restarting the chip can reset all the processor cores, hardware resources, and related software states within the chip, eliminating possible deep-seated hardware or software faults. After the chip restart is completed, the abnormal scene in the first system domain is destroyed, and at this time, no debugging is required.

[0186] For example, when the autonomous driving assistance system (first system domain) of a car fails to connect with the remote monitoring center (communicated through the second system domain), first attempt to restart the operating system of the autonomous driving assistance system, but the problem still exists. At this time, the entire chip responsible for this function is restarted.

[0187] When this application is used, the following situations are included:

[0188] ① After the second program in the second system domain receives the operation abnormal signal and the startup status signal of the first program in the first system domain, it attempts to establish a connection with the first program in the first system domain.

[0189] The second system domain continuously monitors the connection process and determines whether the connection is successfully established. If situations such as timeout, connection error prompt, and inability to establish a communication channel occur during the connection process, it is determined that the second system domain fails to connect to the first program in the first system domain through the second program.

[0190] After determining the connection failure, first attempt to restart the first operating system in the first system domain. The second system domain sends a restart instruction to the first system domain, and the first operating system shuts down the running processes according to the normal restart process, re-initializes the system resources, and then starts again.

[0191] Among them, when restarting the first operating system, the second operating system returns to re-monitoring the operation abnormal signal of the first system domain. If the first operating system runs without abnormalities after restarting, there is no need to continue debugging the first operating system. Because once the first operating system is restarted, the abnormal scene is destroyed, and at this time, there is no need to continue debugging.

[0192] ② When the connection between the second system domain and the first program in the first system domain fails through the second program, a reboot operation is performed on the entire chip.

[0193] The second operating system in the second system domain cuts off the power supply of the chip and then powers it on again, re-initializing each processor core and hardware resource within the chip. After the chip reboot is completed, the exception context in the first system domain is destroyed, and debugging is not required at this time.

[0194] ③ When rebooting the first operating system fails to solve the connection problem and the first operating system cannot be restored to normal operation, the second operating system can reboot the entire SoC chip.

[0195] The second operating system in the second system domain cuts off the power supply of the chip and then powers it on again, re-initializing each processor core and hardware resource within the chip. After the chip reboot is completed, the exception context in the first system domain is destroyed, and debugging is not required at this time.

[0196] For example, when an abnormality occurs in the battery management system (the first system domain) of an electric vehicle, the vehicle's remote diagnostic system (the second system domain) is ready to debug it.

[0197] After the second program of the remote diagnostic system receives the operation abnormality signal from the battery management system, it attempts to establish a connection with the first program of the battery management system. During the connection process, "Connection timed out, unable to establish communication" is displayed, indicating that the connection has failed.

[0198] The remote diagnostic system sends a reboot instruction to the battery management system, and the operating system of the battery management system starts to reboot. After the reboot is completed, the exception context in the first system domain is destroyed, and debugging is not required at this time.

[0199] If rebooting the first operating system fails to solve the connection problem, the vehicle's remote diagnostic system reboots the entire multi-core heterogeneous chip. After the chip is rebooted, the exception context in the first system domain is destroyed, and debugging is not required at this time.

[0200] This application re-initializes the system by rebooting the first operating system and the chip, which can repair system errors to a certain extent, restore the system to normal operation, protect system resources, and avoid further damage to the system caused by continuous abnormal states. Moreover, the exception context is destroyed after each reboot, avoiding meaningless debugging, saving time and resources, and improving the efficiency of fault handling.

[0201] In one embodiment, the method further includes:

[0202] In the case where it is determined that the start status signal of the first program in which the second system domain monitors the first system domain is a start failure signal, restart the first operating system of the first system domain and / or the chip.

[0203] In this embodiment, the start failure signal means that the first program used to debug the system domain in the first system domain fails to start successfully during the start-up process. The first system domain will send a corresponding signal indicating start failure, and this signal contains relevant information about the start failure, such as possible error codes, error descriptions, etc.

[0204] For example, in an automatic transmission control system (the first system domain) of a car, the first program is used to debug the shift logic of the transmission. When starting this program, due to damage to the firmware of the transmission control unit, the program cannot normally load the necessary driver programs, and the first system domain sends a start failure signal "The first program fails to start, error code 003: Firmware loading exception".

[0205] After receiving the start failure signal of the first program, perform a restart operation on the first operating system running in the first system domain. The purpose is to try to restore the normal state of the first operating system and eliminate the abnormal scene.

[0206] For example, in a tire pressure monitoring system (the first system domain) of a car, the first program fails to start. At this time, restart the operating system of the tire pressure monitoring system.

[0207] When receiving the start failure signal of the first program or restarting the first operating system fails to solve the problem of the first program failing to start, the second operating system of the second system domain restarts the entire multi-core heterogeneous chip. Restarting the chip can reset all the processor cores, hardware resources, and related software states in the chip, eliminating possible deep-seated hardware or software faults. After the chip restart is completed, the abnormal scene in the first system domain is destroyed, and at this time, no debugging is required.

[0208] For example, in an intelligent driving vision system (the first system domain) of a car, the first program fails to start multiple times, and there is still no improvement after trying to restart the operating system of the system. At this time, restart the entire chip responsible for intelligent driving vision processing.

[0209] When this application is used, it includes the following situations:

[0210] ① The second monitoring module of the second system domain continuously pays attention to the start status signal of the first program in the first system domain. When the first program starts, the first system domain will send a corresponding start status signal, and the second monitoring module receives and analyzes this signal.

[0211] If the received startup status signal indicates that the startup of the first program fails, the second system domain determines the situation of the startup failure according to the error information in the signal.

[0212] After determining that the startup of the first program fails, the second system domain sends a restart instruction to the first system domain. The first operating system of the first system domain shuts down the running processes according to the normal restart process, re-initializes the system resources, and then starts again.

[0213] After the first operating system restarts successfully, the exception context of the first system domain is destroyed, and debugging is not required at this time. If the startup still fails, proceed to the next step (i.e., restart the entire chip through the second operating system of the second system domain).

[0214] ② When the received startup status signal indicates that the startup of the first program fails, perform a restart operation on the entire chip.

[0215] The second operating system of the second system domain cuts off the power supply of the chip, and then powers on again to re-initialize each processor core and hardware resource in the chip. After the chip restart is completed, the exception context of the first system domain is destroyed, and debugging is not required at this time.

[0216] ③ When restarting the first operating system cannot make the first operating system work properly, the second operating system of the second system domain can be used to restart the entire SoC chip at this time.

[0217] The second operating system of the second system domain cuts off the power supply of the chip, and then powers on again to re-initialize each processor core and hardware resource in the chip. After the chip restart is completed, the exception context of the first system domain is destroyed, and debugging is not required at this time.

[0218] For example, if there is a problem with the engine ignition control system (the first system domain) of a car, the vehicle diagnostic system (the second system domain) is responsible for debugging it.

[0219] The second monitoring module of the diagnostic system monitors the startup of the first program of the engine ignition control system, and then receives a startup failure signal "The startup of the first program fails, error code 005: Error in reading ignition control parameters".

[0220] The diagnostic system sends a restart instruction to the engine ignition control system, and the first operating system of this system restarts. After the restart is completed, the exception context of the first system domain is destroyed, and debugging is not required at this time.

[0221] If restarting the first operating system fails to solve the problem, the vehicle diagnostic system restarts the entire multi-core heterogeneous chip. After the chip restarts, the exception context of the first system domain is destroyed, and debugging is not required at this time.

[0222] This application re-initializes the system by restarting the first operating system and the chip, which can repair system errors to a certain extent, restore the normal operation of the system, protect system resources, and prevent further damage to the system caused by continuous abnormal states. Moreover, the abnormal scene is destroyed after each restart, avoiding meaningless debugging, saving time and resources, and improving the efficiency of fault handling.

[0223] In summary, when this application is applied, as Figure 5 and Figure 6 shown, the debugging process between two system domains (Domain-0 and Domain-1) in a heterogeneous multi-core system, where Domain-0 is the first system domain and Domain-1 is the second system domain, is as follows:

[0224] After the first operating system of Domain-0 starts, it activates the watchdog program (the first monitoring module), and the watchdog program continuously monitors the system running state, mainly checking whether the system gets stuck.

[0225] If the watchdog program detects that the system is stuck (i.e., an exception occurs), or the system itself has an exception and triggers a panic (crash) state, the system will switch to the debug service mode. Among them, if the system is detected to be stuck by the watchdog program, the watchdog program will switch the system to the debug mode.

[0226] After switching to the service debug mode, Domain-0 will send a system exception signal to Domain-1, informing it that it has an exception and needs debugging. Then it starts the debug service. If the debug service starts successfully, it will send a start success signal to Domain-1; if the start fails, it will send a start failure signal to Domain-1.

[0227] After the second operating system of Domain-1 starts, it starts the monitor program (the second monitoring module), which is mainly responsible for listening for the exception signals sent by Domain-0.

[0228] When Domain-1 receives the exception signal from Domain-0, it starts to monitor the status of the debug service program (the first program) in Domain-0.

[0229] If it is found that the debug service program of Domain-0 starts normally, Domain-1 will start the debug client program (the second program) to connect to the debug service program (the first program). If the connection is successful, commands can be input to debug the abnormal system of Domain-0, realizing the function of remote debugging.

[0230] If the connection fails, the first operating system or the chip of Domain-0 will be considered for restart to attempt to solve the connection problem and create conditions for re-debugging.

[0231] Among them, after the first operating system is restarted, the abnormal scene is destroyed, and there is no need to continue debugging at this time. If the system still cannot work properly after restarting the first operating system alone, then let the second operating system restart the entire SoC chip. After the chip restart is completed, the abnormal scene in the first system domain is destroyed, and there is no need to debug at this time.

[0232] In addition, if the startup of the debug client program (the second program) in the second system domain (Domain-1) fails or the connection fails during the debugging process, the corresponding processing methods described above are also followed, such as restarting the first operating system or the chip in the first system domain to solve the problem, ensuring that the entire debugging process can proceed smoothly, and troubleshooting and resolving the abnormalities that occur in the system domain.

[0233] The embodiment of the present application also provides a debugging device, which is applied to a chip including multiple different processor cores. The processor cores and their corresponding hardware resources are configured as corresponding system domains, and operating systems are respectively configured to run within the system domains, and inter-core communication can be performed between multiple system domains.

[0234] As Figure 7 shown, the debugging device includes:

[0235] An acquisition module configured to acquire the running state of the first operating system of the first system domain, where the first system domain is one of the multiple system domains;

[0236] A switching module configured to switch the first operating system to a debug service mode when it is determined that the first operating system is abnormal;

[0237] A sending module configured to send an operation abnormal signal of the first operating system and a startup state signal of the first program to the second system domain based on the debug service mode, where the second system domain is a system domain different from the first system domain among the multiple system domains, and the first program is used to debug the first system domain;

[0238] A debugging module configured to determine to debug the first system domain based on the connection state signal of the second program in the second system domain, where the second program is a program used by the second system domain to provide remote debugging for the first system domain.

[0239] It should be noted that the principle of the debugging device provided in the embodiments of the present application for solving technical problems is similar to that of the debugging method provided in the embodiments of the present application. Therefore, for the implementation of the debugging device provided in the embodiments of the present application, reference can be made to the implementation of the debugging method provided in the embodiments of the present application, and repeated parts will not be elaborated.

[0240] The embodiments of the present application further provide an electronic device, including a processor and a storage device. An executable program is stored in the storage device, and the storage device executes the executable program to perform the steps of the method as described above.

[0241] The embodiments of the present application provide a computer program product, including a computer program / instructions. When the computer program / instructions are executed by a processor, the steps of the display method as described above are implemented.

[0242] The embodiments of the present application provide a storage medium, which carries one or more computer programs. When the one or more computer programs are executed by a processor, the steps of the method as described above are implemented.

[0243] The vehicle in the embodiments of the present application may be "automobile", "vehicle" and "whole vehicle" or other similar terms, including general motor vehicles, such as cars, SUVs, MPVs, buses, trucks and other cargo or passenger vehicles, water transportation tools including various ships and boats, and aircrafts, etc., including hybrid vehicles, electric vehicles, fuel vehicles, plug-in hybrid vehicles, fuel cell vehicles and other alternative fuel vehicles. Among them, a hybrid vehicle refers to a vehicle with two or more power sources, and an electric vehicle includes a pure electric vehicle, an extended-range electric vehicle, etc. The present application does not make specific limitations in this regard.

[0244] It should be understood that in the embodiments of the present application, the processor may be a central processing unit (CPU for short), and the processor may also be other general-purpose processors, digital signal processors (DSP for short), application specific integrated circuits (ASIC for short), field-programmable gate arrays (FPGA for short) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0245] It should also be understood that the memory mentioned in the embodiments of the present invention can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchlink dynamic random access memory (SLDRAM), and direct rambus random access memory (DR RAM).

[0246] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, the memory (storage module) is integrated in the processor.

[0247] It should be noted that the memory described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0248] In addition to the data bus, this bus can also include a power bus, a control bus, a status signal bus, etc. However, for the sake of clarity, all kinds of buses are labeled as buses in the figure.

[0249] It should also be understood that the first, second, third, fourth, and various digital numbers involved herein are only for the convenience of description and are not used to limit the scope of this application.

[0250] It should be understood that the term "and / or" in this text is merely a description of the associated relationship between associated objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. Additionally, the character " / " in this text generally indicates that the associated objects before and after are in an "or" relationship.

[0251] In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in the processor or the instructions in the form of software. The steps of the method disclosed in combination with the embodiments of the present application can be directly embodied as being executed and completed by the hardware processor, or executed and completed by the combination of the hardware and software modules in the processor. The software module can be located in the random access memory, flash memory, read-only memory, programmable read-only memory, or electrically erasable programmable memory, registers, and other mature storage media in the art. This storage media is located in the memory, and the processor reads the information in the memory and combines its hardware to complete the steps of the above method. To avoid repetition, it will not be described in detail here.

[0252] In various embodiments of the present application, the magnitude of the serial numbers of the above processes does not mean 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 to the implementation process of the embodiments of the present application.

[0253] Those of ordinary skill in the art can realize that the various illustrative logical blocks (ILB) and steps described in combination with the embodiments disclosed in this text can be implemented by electronic hardware, or by the combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professionals can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0254] In several embodiments provided by the present application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection to each other can be through some interfaces. The indirect coupling or communication connection of the devices or units can be in an electrical, mechanical, or other form.

[0255] The unit described as a separation component may or may not be physically separated. The component displayed as a unit may or may not be a physical unit, that is, it may be located in one place or distributed over multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0256] In addition, in each embodiment of the present application, each functional unit can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit.

[0257] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center by wire (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid-state drive), etc.

[0258] The above is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present application, and all of them should be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A debugging method, characterized in that: Applied to a chip including a plurality of different processor cores, the processor cores and their corresponding hardware resources are configured as corresponding system domains, the system domains are respectively configured to run operating systems, and the plurality of system domains can perform inter-core communication, the debugging method comprises: Acquire a running state of a first operating system of a first system domain, wherein the first system domain is one of the plurality of system domains; If it is determined that the first operating system is abnormal, switching the first operating system to a debugging service mode; Based on the debugging service mode, the first system domain sends an operation abnormality signal of the first operating system and a startup status signal of the first program to a second system domain, wherein the second system domain is a system domain different from the first system domain among the plurality of system domains, and the first program is used to debug the first system domain; Based on a connection status signal of a second program of the second system domain, it is determined to debug the first system domain, wherein the second program is a program used by the second system domain to provide remote debugging for the first system domain.

2. The debugging method according to claim 1, characterized in that: A first monitoring module is provided in the system domain, and determining that the first operating system is abnormal includes: The first operating system monitors a first abnormal event; Or, the first monitoring module monitors a second abnormal event, wherein the first abnormal event and the second abnormal event are of different types.

3. The debugging method according to claim 1, characterized in that: A second monitoring module is also provided in the system domain, and the method further includes: Based on the second monitoring module, the second system domain monitors an operation abnormality signal of the first operating system sent by the first system domain; Based on the operation abnormality signal, the second system domain monitors a startup status signal of the first program in the first system domain.

4. The debugging method according to claim 3, characterized in that: The method further comprises: In the case that the plurality of second system domains all monitor the operation abnormality signal of the first operating system sent by the first system domain, determining the operation status of the plurality of second system domains; Based on the running status, one of the second system domains is determined as a system domain for debugging the first system domain.

5. The debugging method according to claim 3, characterized in that: The method further comprises: When it is determined that the startup of the second program is abnormal, the first operating system of the first system domain and / or the chip are restarted.

6. The debugging method according to claim 3, characterized in that: The method further comprises: When it is determined that the second system domain fails to connect to the system domain through the second program, the first operating system and / or the chip of the first system domain are restarted.

7. The debugging method according to claim 3, characterized in that: The method further comprises: When it is determined that the startup status signal of the first program in the first system domain monitored by the second system domain is a startup failure signal, the first operating system and / or the chip in the first system domain is restarted.

8. A debugging device, characterized in that: Applied to a chip including a plurality of different processor cores, the processor cores and their corresponding hardware resources are configured as corresponding system domains, the system domains are respectively configured to run operating systems, and the plurality of system domains can perform inter-core communication, the debugging device comprises: an acquisition module configured to acquire a running state of a first operating system of a first system domain, wherein the first system domain is one of the plurality of system domains; a switching module configured to switch the first operating system to a debugging service mode when determining that the first operating system is abnormal; a sending module configured to, based on the debugging service mode, cause the first system domain to send an operation abnormality signal of the first operating system and a startup status signal of the first program to a second system domain, wherein the second system domain is a system domain different from the first system domain among the plurality of system domains, and the first program is used to debug the first system domain; The debugging module is configured to determine to debug the first system domain based on a connection status signal of a second program of the second system domain, wherein the second program is a program used by the second system domain to provide remote debugging for the first system domain.

9. An electronic device, characterized in that: The method comprises a processor and a storage device, wherein the storage device stores an executable program, and the storage device executes the executable program to perform the steps of the method according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium carries one or more computer programs, and when the one or more computer programs are executed by the processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images