Fault positioning method for heterogeneous multi-core processor

Abstract

The invention provides a fault positioning method for a heterogeneous multi-core processor, and relates to the technical field of embedded systems, comprising the following steps: S1, loading a master core and a slave core, and completing initialization operation; s2, creating a shared memory area, and updating the heartbeat count to the shared memory area during verification; s3, reading the heartbeat count of the slave core by the master core, and judging whether the slave core is abnormal or not; s4, querying a chip manual, and resetting an abnormal slave core; s5, the abnormal slave core loads the applet, and memory information is DUMP to the specified DDR; and S6, exporting memory information from the DUMP to the DDR into a file, and analyzing the file to locate a fault. The method has the advantages that abnormity monitoring is achieved through the concept of the master core and the slave core and the heartbeat mechanism, meanwhile, the core memory of the abnormal core can be automatically exported, and the efficiency and accuracy of fault positioning are effectively improved.

Description

Technical Field

[0001] The present invention relates to the technical field of embedded systems, and in particular to a fault locating method for a heterogeneous multi-core processor. Background Art

[0002] As technology advances, high-intensity, multi-dimensional computing scenarios are becoming more common, and heterogeneous multi-core architectures are being widely used. As hardware architectures become more and more complex, software architectures are also becoming more and more complex.

[0003] In the prior art, some chips are designed so that the core memory in the core cannot be directly accessed from the outside world for multiple reasons such as nuclear safety. That is, when the core is abnormal, the core memory of the core cannot be obtained through other cores. When the entire software is running to execute related services, a processor or some processors fail, and the operating system and processor themselves do not support the debugging module, the only way to troubleshoot is to check logs and walk through the code, which requires a lot of manpower and time.

[0004] How to solve the above technical problems is the subject faced by the present invention. Summary of the invention

[0005] In order to solve the deficiencies of the prior art, the present invention provides a fault location method for a heterogeneous multi-core processor with high fault location efficiency and high accuracy.

[0006] The technical solution adopted by the present invention to solve the technical problem is: the present invention provides a fault location method for a heterogeneous multi-core processor, comprising the following steps:

[0007] S1, load the master core and slave core, and complete the initialization operation;

[0008] The initialization of the master core and slave core includes setting the initial values ​​of their respective registers, initializing the internal cache, configuring the interrupt vector table, and establishing the initial connection with the external device. During the initialization process, the master core and slave core perform integrity and functionality checks on their key hardware modules through the built-in self-test program.

[0009] S2, create a shared memory area, and update the heartbeat count from the core to the shared memory area;

[0010] S3, the master core reads the heartbeat count of the slave core and determines whether the slave core is abnormal;

[0011] S4. Check the chip manual and reset the abnormal slave core;

[0012] S5, abnormally load the small program from the core and dump the core memory to the specified DDR;

[0013] S5. Export the core memory dumped to DDR into a file and analyze the file to locate the fault.

[0014] Through the exported files, technicians can analyze the stack status information, function calling relationships, and operating values ​​of various parameters before the core failure, so as to accurately locate the root cause of the failure, shorten the troubleshooting cycle, improve the efficiency of fault repair, and provide strong support for the long-term stable operation of the system. It also provides valuable actual failure data reference for subsequent chip design optimization.

[0015] Preferably, the step S2 is specifically:

[0016] Define the starting address and size information of the shared memory area in the system, inform the master core and the slave core, set the heartbeat update time, and the slave core periodically updates the heartbeat count to the shared memory area according to the heartbeat update time.

[0017] The master-slave core concept is adopted to realize abnormal monitoring and centralized management, optimizing the fault location process.

[0018] Preferably, the step S3 is specifically:

[0019] The master core periodically reads the heartbeat count of the slave core from the shared memory area. When the heartbeat update time is reached and the slave core has not updated the heartbeat count, the master core puts the slave core into the list of possible abnormal slave cores and continuously monitors it.

[0020] If the slave core jump count is updated within the continuous monitoring times, the slave core is removed from the list of possible abnormal slave cores;

[0021] If the slave core hop count is not updated within the number of consecutive monitoring times, the slave core is determined to be unable to self-recover and is moved into the abnormal slave core list.

[0022] The heartbeat mechanism is used to continuously monitor slave cores that may be abnormal, to avoid misjudgment caused by the processor's failure to update the heartbeat count in time when there are sudden situations during business operations. This improves the accuracy of fault location, avoids unnecessary operations on normally operating slave cores due to incorrect fault judgments, and ensures the stability and reliability of the system.

[0023] Preferably, when resetting the abnormal slave core in step S4, a partial core software reset mechanism is adopted, and the software reset register address and reset operation mode of the abnormal slave core are obtained by querying the chip manual to reset the abnormal slave core.

[0024] By adopting the partial core software reset mechanism, the abnormal core can be reset without affecting the operation of other cores, reducing the system downtime caused by partial core abnormalities and the potential damage risk to the system hardware caused by frequent overall resets.

[0025] Preferably, the applet in step S5 is an assembly instruction written in assembly language according to chip information. After the abnormal core is reset, the core memory is dumped to the specified DDR by loading the applet, and the address of the core memory and the address of the DDR are clearly indicated in the assembly instruction.

[0026] Assembly language is used to write assembly instructions to dump the core memory into the specified DDR, which realizes the automatic export of the core memory of the abnormal core. There is no stack call, which will not damage the core memory of the abnormal core, ensuring the integrity and reliability of the core memory data, thereby improving the accuracy of fault location analysis.

[0027] The beneficial effects of the present invention are as follows: high efficiency and high accuracy in fault location. The concept of master-slave core is adopted to realize abnormal monitoring and centralized management, and the fault location process is optimized. The heartbeat mechanism is used to continuously monitor the slave core that may be abnormal, so as to avoid misjudgment caused by the processor's failure to update the heartbeat count in time when there is a sudden situation during the business, thereby improving the accuracy of fault location, avoiding unnecessary operations on the slave core that is operating normally due to wrong fault judgment, and ensuring the stability and reliability of the system. The partial core software reset mechanism is adopted to realize the reset of the abnormal core without affecting the operation of other cores, reduce the system downtime caused by partial core abnormalities, and also reduce the potential risk of damage to the system hardware caused by frequent overall reset. The assembly language is used to write assembly instructions to dump the core memory into the specified DDR, so as to realize the automatic export of the core memory of the abnormal core, and there is no stack call, so the core memory of the abnormal core will not be destroyed, which ensures the integrity and reliability of the core memory data, thereby improving the accuracy of fault location analysis. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 It is a schematic diagram of the process of the present invention.

[0029] Figure 2 Schematic diagram of the master-slave core jump mechanism of the present invention. DETAILED DESCRIPTION

[0030] In order to clearly illustrate the technical features of this solution, this solution is described below through specific implementation methods.

[0031] See also Figure 1 , Figure 2 As shown, this embodiment is a fault location method for a heterogeneous multi-core processor, comprising the following steps:

[0032] S1, load the master core and slave core, and complete the initialization operation;

[0033] The initialization of the master core and the slave core includes setting the initial values ​​of their respective registers, initializing the internal cache, configuring the interrupt vector table, and establishing the initial connection with the external device. During the initialization process, the master core and the slave core perform integrity and functionality checks on their key hardware modules through the built-in self-test program, ensuring that the hardware and software environment are in the preset normal state, avoiding misjudgment of faults caused by improper initial configuration, and thus improving the accuracy and reliability of fault location.

[0034] S2, create a shared memory area, and update the heartbeat count from the core to the shared memory area;

[0035] S3, the master core reads the heartbeat count of the slave core and determines whether the slave core is abnormal;

[0036] S4. Check the chip manual and reset the abnormal slave core;

[0037] S5, abnormally load the small program from the core and dump the core memory to the specified DDR;

[0038] S5. Export the core memory dumped to DDR into a file and analyze the file to locate the fault.

[0039] Through the exported files, technicians can analyze the stack status information, function calling relationships, and operating values ​​of various parameters before the core failure, so as to accurately locate the root cause of the failure, shorten the troubleshooting cycle, improve the efficiency of fault repair, and provide strong support for the long-term stable operation of the system. It also provides valuable actual failure data reference for subsequent chip design optimization.

[0040] Step S2 is specifically as follows:

[0041] Define the starting address and size information of the shared memory area in the system, inform the master core and the slave core, set the heartbeat update time, and the slave core will update the heartbeat count to the shared memory area according to the heartbeat update time. The master-slave core concept is used to implement abnormal monitoring and centralized management, optimizing the fault location process.

[0042] Step S3 is specifically as follows:

[0043] The master core periodically reads the heartbeat count of the slave core from the shared memory area. When the heartbeat update time is reached and the slave core has not updated the heartbeat count, the master core puts the slave core into the list of possible abnormal slave cores and continuously monitors it.

[0044] If the slave core jump count is updated within the continuous monitoring times, the slave core is removed from the list of possible abnormal slave cores;

[0045] If the slave core hop count is not updated within the number of consecutive monitoring times, the slave core is determined to be unable to self-recover and is moved into the abnormal slave core list.

[0046] The heartbeat mechanism is used to continuously monitor slave cores that may be abnormal, to avoid misjudgment caused by the processor's failure to update the heartbeat count in time when there are sudden situations during business operations. This improves the accuracy of fault location, avoids unnecessary operations on normally operating slave cores due to incorrect fault judgments, reduces unnecessary troubleshooting costs, ensures that system resources can be concentrated on processing the real faulty core, and guarantees the stability and reliability of the system.

[0047] When resetting the abnormal slave core in step S4, a partial core software reset mechanism is adopted, and the software reset register address and reset operation mode of the abnormal slave core are obtained by querying the chip manual to reset the abnormal slave core.

[0048] By querying the chip manual to obtain the accurate reset register address and operation method, the abnormal slave core can be reset in a targeted manner, avoiding a full restart of the entire system. This not only reduces system downtime and data loss risks, but also restores the abnormal slave core function without affecting the normal operation of other slave cores, greatly improving the system's availability and fault tolerance, allowing the system to quickly self-repair in the face of slave core failures and maintain business continuity. Reducing system downtime caused by partial core anomalies also reduces the risk of potential damage to system hardware caused by frequent overall resets.

[0049] The applet in step S5 is an assembly instruction written in assembly language according to chip information. After the abnormal core is reset, the core memory is dumped to the specified DDR by loading the applet. The address of the core memory and the address of the DDR are clearly indicated in the assembly instruction.

[0050] Assembly language is used to write assembly instructions to dump the core memory into the specified DDR, which realizes the automatic export of the core memory of the abnormal core. There is no stack call, which will not damage the core memory of the abnormal core, ensuring the integrity and reliability of the core memory data, thereby improving the accuracy of fault location analysis.

[0051] Technical features not described in the present invention can be achieved through or by adopting existing technologies and will not be described in detail here. Of course, the above description is not a limitation of the present invention, and the present invention is not limited to the above examples. Changes, modifications, additions or substitutions made by ordinary technicians in this technical field within the essential scope of the present invention should also fall within the scope of protection of the present invention.

Claims

1. A method for locating a fault in a heterogeneous multi-core processor, characterized in that: The following steps are involved: S1, load the master core and slave core, and complete the initialization operation; S2, create a shared memory area, and update the heartbeat count from the core to the shared memory area; S3, the master core reads the heartbeat count of the slave core and determines whether the slave core is abnormal; S4. Check the chip manual and reset the abnormal slave core; S5, abnormally load the small program from the core and dump the memory information to the specified DDR; S6. Export the memory information dumped to DDR into a file and analyze the file to locate the fault.

2. The method for locating a fault in a heterogeneous multi-core processor according to claim 1, characterized in that: The step S2 is specifically as follows: Define the starting address and size information of the shared memory area in the system, inform the master core and the slave core, set the heartbeat update time, and the slave core periodically updates the heartbeat count to the shared memory area according to the heartbeat update time.

3. The method for locating a fault in a heterogeneous multi-core processor according to claim 1, characterized in that: The step S3 is specifically as follows: The master core periodically reads the heartbeat count of the slave core from the shared memory area. When the heartbeat update time is reached and the slave core has not updated the heartbeat count, the master core puts the slave core into the list of possible abnormal slave cores and continuously monitors it. If the slave core jump count is updated within the continuous monitoring times, the slave core is removed from the list of possible abnormal slave cores; If the slave core hop count is not updated within the number of consecutive monitoring times, the slave core is determined to be unable to self-recover and is moved into the abnormal slave core list.

4. The method for locating a fault in a heterogeneous multi-core processor according to claim 1, characterized in that: When resetting the abnormal slave core in step S4, a partial core software reset mechanism is adopted, and the software reset register address and reset operation mode of the abnormal slave core are obtained by querying the chip manual to reset the abnormal slave core.

5. The method for locating a fault in a heterogeneous multi-core processor according to claim 1, characterized in that: The mini-program in step S5 is an assembly instruction written in assembly language according to chip information.

Images