Inter-core communication path abnormal state recovery method and device and storage medium

Abstract

The invention relates to the technical field of communication, in particular to an inter-core communication path abnormal state recovery method and device and a storage medium, and the method comprises the steps: obtaining the operation states of a host end and a slave end; under the condition that the operation state of the host end is an abnormal state and the operation state of the slave end is a normal state, determining the type of an inter-core communication message; if the type of the inter-core communication message is a preset type, determining whether the host end has no alarm reset; and if the host side has no alarm reset, establishing a communication path between the host side and the slave side based on a first handshake process. According to the method, a path between a host end and a slave end is re-established, and transmission of service data is recovered, so that the path can recover communication at the highest speed after a single end is abnormally reset.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of communication technology, in particular to a method and device for recovering from abnormal state of inter-core communication channel and storage medium. BACKGROUND

[0002] In the internal of a system on chip (SoC), when a host user thread is hung up but a slave is running normally, the IPC interface can only be re-linked after the slave is restarted, and when the host user thread is restarted but the slave is still alive, the channel cannot be established, and the host user thread and the slave need to be restarted by a special mechanism to be normal, which consumes a long time. SUMMARY

[0003] The present application aims to provide a method and device for recovering from abnormal state of inter-core communication channel and storage medium, and the technical solutions are as follows: In a first aspect, the present application provides a method for recovering from abnormal state of inter-core communication channel, which comprises: acquiring running states of a host and a slave; determining a type of inter-core communication message when the running state of the host is an abnormal state and the running state of the slave is a normal state; determining whether the host is reset without alarm if the type of the inter-core communication message is a preset type; establishing a communication channel between the host and the slave based on a first handshake process if the host is reset without alarm.

[0004] In a second aspect, the present application provides a device for recovering from abnormal state of inter-core communication channel, which comprises: an acquiring module configured to acquire running states of a host and a slave; a first determining module configured to determine a type of inter-core communication message when the running state of the host is an abnormal state and the running state of the slave is a normal state; a second determining module configured to determine whether the host is reset without alarm if the type of the inter-core communication message is a preset type; an establishing module configured to establish a communication channel between the host and the slave based on a first handshake process if the host is reset without alarm.

[0005] In a third aspect, a computer program product is provided, which comprises computer program code, which, when run on a computer, causes the computer to perform the method of the first aspect.

[0006] In a fourth aspect, a computer readable storage medium is provided, which stores computer program code, which, when run on a computer, causes the computer to perform the method of the first aspect.

[0007] The present application has the following beneficial effects: after obtaining the running states of the host end and the slave end, in the case that the running state of the host end is an abnormal state and the running state of the slave end is a normal state, the type of the inter-core communication message is determined; in this way, in the case that the host end is hung up but the slave end is normally running, it is judged whether the type of the inter-core communication message represents that the channel is being opened, if the type of the inter-core communication message represents that the channel is being opened, it is determined whether the host end is reset without alarm, and if the host end is reset without alarm, the communication path between the host end and the slave end is established based on the first handshake process. In this way, after the host end is abnormally restarted without informing the slave end, by judging the type of the inter-core communication message, if the type of the inter-core communication message represents that the channel is being opened, the path between the host end and the slave end is re-established, and the transmission of the service data is resumed, so as to ensure that the path can be resumed to communicate at the fastest speed after the single-end abnormal reset. BRIEF DESCRIPTION OF DRAWINGS

[0008] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, and the advantages thereof, the drawings needed to be used in the embodiments or the prior art description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained from these drawings without any creative effort.

[0009] Figure 1 Fig. 1 is an implementation framework schematic diagram of a path abnormal state recovery method of inter-core communication provided by some embodiments of the present application; Figure 2 Fig. 2 is an implementation flow schematic diagram of a path abnormal state recovery method of inter-core communication provided by the embodiments of the present application; Figure 3 Fig. 3 is another implementation flow schematic diagram of a path abnormal state recovery method of inter-core communication provided by the embodiments of the present application; Figure 4 Fig. 4 is an implementation framework schematic diagram of a path abnormal state recovery method of inter-core communication provided by the embodiments of the present application; Figure 5is a component structure schematic diagram of a path abnormal state recovery device for inter-core communication provided by an embodiment of the present application; Figure 6 is a structure schematic diagram of a computer device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0010] In order to further illustrate the technical means and effects taken by the present application to achieve the predetermined object of the application, the following describes in detail the specific implementation, structure, features and effects of a path abnormal state recovery method for inter-core communication according to the present application, in combination with the accompanying drawings and preferred embodiments. In the following description, different "one embodiment" or "another embodiment" do not necessarily refer to the same embodiment. In addition, the specific features, structures or characteristics in one or more embodiments can be combined in any suitable form.

[0011] In the description of the embodiments of the present application, unless otherwise specified, " / " represents the meaning of or, for example, A / B can represent A or B: "and / or" in the text is only a description of the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent: A exists alone, A and B exist together, and B exists alone, in addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0012] Hereinafter, the terms "first", "second" are only used for description purposes, and cannot be understood as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Therefore, the features defined with "first", "second" can explicitly or implicitly include one or more of the features.

[0013] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs.

[0014] In some embodiments, inter-processor communication (IPC) is based on interrupt (IPI, GPIO or Mailbox IRQ mode) notification or the way that the logical control unit (Mailbox) of multi-core communication carries data and interrupts notification to format and manage shared memory data and simplify the module of application data transmission. Overall, the operation of application processor (AP) and coprocessor (CP2) on shared memory is the core: each business module calls the read-write interface of the stream data transmission module / block data transmission module (SBUF / SBLOCK) of the IPC to transmit data, and then the driving part of the IPC transmits the inter-processor communication message (MSG) through inter-processor communication to complete the real data transmission operation.

[0015] The inter-processor communication message consists of four members: channel index, type, flag and value. The channel index is the index of the inter-processor communication message, the type indicates the message type, and the flag and the value can be selected by the interface used.

[0016] The specific creation process of the inter-processor communication message consists of two handshakes, as shown in Figure 1 The specific creation process of the inter-processor communication message includes: host user thread (Host USER Thread) (i.e. host end) 101, IPI / MAILBOX 102, IPI / MAILBOX 103, client user thread (Client USER Thread) (i.e. slave end) 104. The host user thread and the client user thread complete the handshake and channel creation through the combination of open command (OPEN) \ open response command (OPEN ACK) \ initialization end command (INITDONE) and the like, and when the channel creation is completed, the subsequent inter-processor communication message is used to notify the read-write operation of the IPC of different cores (CORE).

[0017] In the embodiment of the application, for the scenario of no pre-warning abnormality at one end: After the inter-core communication message is created, the IPC thread only judges the flags in the inter-core communication message. The SBUF_EVENT_RDPTR_CHANGE or SBUF_EVENT_WRPTR_CHANGE in the flag information is used to trigger different channels for read and write operations, and the handshake process depends on the type of the inter-core communication message.

[0018] In the above scenario, when the slave end is in the state where the thread has been successfully created and is waiting for the flag information in the inter-core communication message of the peer end to perform the channel (chn) operation, while the host end user thread is in the stage where the channel has not been created, the host end user thread needs to send a message of type MSG_TYPE_OPEN and wait for the peer end's OPEN_ACK. Since the peer end does not judge the type, the handshake falls into a dead end where it cannot reply and wait. This situation cannot be repaired after the slave end is restarted. After the slave end is restarted, it will actively send a message of type MSG_TYPE_OPEN (IPC open type command) to the host end user thread. The host end user thread will now think that this inter-core communication message is the OPEN_ACK replied by the peer end last time. The confusion of the handshake process eventually causes the host end user thread and the slave end to fall into an embarrassing situation where they can only be recovered after restarting again.

[0019] Based on this, an embodiment of the present invention provides an apparatus for recovering an abnormal state of a path in inter-core communication. The following describes a specific solution of a method for recovering an abnormal state of a path in inter-core communication provided by the present invention in conjunction with the accompanying drawings. Figure 2 , which shows a schematic diagram of an implementation flow of a method for recovering from an abnormal state of an inter-core communication path provided by an embodiment of the present invention, the method comprising: 201, obtain the running status of the host and the slave.

[0020] Here, the operating status of the host side and the operating status of the slave side are detected in real time to determine whether the operating status of the host side and the operating status of the slave side are abnormal.

[0021] 202 : When the running state of the host side is abnormal and the running state of the slave side is normal, determine the type of the inter-core communication message.

[0022] Here, the abnormal state can be an idle state, a fault state, etc. If the host side is in an abnormal state and the slave side is in a normal operating state, it means that the host side has an abnormality and cannot notify the slave side, so it automatically restarts. Furthermore, the type of the inter-core communication message is polled to determine whether the type of the inter-core communication message is a preset type.

[0023] In some possible implementation manners, in a case where the running state of the host end is an abnormal state and the running state of the slave end is a normal state, the host end is controlled to be actively restarted, and a streaming data transmission thread of the slave end is determined; in the streaming data transmission thread, the type of the inter-core communication message of the host end is judged.

[0024] Here, if the host end is abnormal and the slave end is normal, the host end is actively restarted, and a module (an IPC FIFO buffer interface module thread, SBUF thread) corresponding to the streaming data transmission thread of the slave end is determined, and in the module, the inter-core communication message of the slave end is additionally judged to analyze whether the type of the inter-core communication message is a preset type, so as to facilitate the message synchronization between the host end and the slave end by judging the type of the inter-core communication message.

[0025] 203, if the type of the inter-core communication message is a preset type, determining whether the host end is reset without alarm.

[0026] Here, the preset type can be a type (type) indicating that the channel is being opened (for example, MSG_TYPE_OPEN, an inter-core communication message indicating that the channel is being opened).

[0027] In some possible implementation manners, if the inter-core communication type is a channel being opened type, a data transmission mode of the inter-core communication message is determined; here, if the type is MSG_TYPE_OPEN (that is, a channel being opened type indicating that the channel is being opened), that is, the inter-core communication type of the inter-core communication message indicates that the channel is being opened, it is further judged whether the data transmission mode of the inter-core communication message is message queue transmission (for example, the data transmission mode is that the inter-core communication message corresponds to data transmission by using a message queue); if it is message queue transmission, it is determined whether the host end is reset without alarm. For example, if the type of the inter-core communication message is MSG_TYPE_OPEN, it is further determined whether the host end is reset without alarm. In this way, the accuracy of the judgment can be improved by multiple progressive judgments.

[0028] In some embodiments, if the type of the inter-core communication message is a non-preset type, the type of the inter-core communication message is polled until the type of the inter-core communication message is a preset type.

[0029] Here, if the type of the inter-core communication message is not MSG_TYPE_OPEN, that is, a non-preset type, the old flow is run, that is, the host end is reset without alarm. Figure 1The flow shown operates to poll the inter-core communication for message types until the type of the inter-core communication message is polled as MSG_TYPE_OPEN.

[0030] In some possible implementation manners, first, if the type of the inter-core communication message is a non-preset type, a polling period of the inter-core communication is acquired; here, the polling period can be a user-defined period or a real-time polling. Then, in a case where the running state of the host end is an abnormal state and the running state of the slave end is a normal state, message types of the inter-core communication are polled based on the polling period until the type of the inter-core communication message is polled as a preset type. Here, in a scenario where the running state of the host end is an abnormal state and the running state of the slave end is a normal state, the slave end polls the inter-core communication message (i.e., a module of message queue data transmission) of the host end in the SBUF thread until the type of the inter-core communication message is polled as MSG_TYPE_OPEN (i.e., a channel is being opened type, that is, a preset type); in this way, in a case where the running state of the host end is an abnormal state and the running state of the slave end is a normal state, a path between the slave end and the host end can be established in time and accurately, so as to realize real-time transmission of messages.

[0031] In some possible implementation manners, in a case where the running state of the host end is an abnormal state and the running state of the slave end is a normal state, a module of message queue data transmission of the inter-core communication of the host end is polled by the slave end according to a polling period, so as to obtain the type of the inter-core communication message. Here, the module of message queue data transmission is polled according to the polling period, so as to determine whether the type of the inter-core communication message in the module is MSG_TYPE_OPEN.

[0032] 204, if the host end has no alarm reset, a communication path between the host end and the slave end is established based on the first handshake flow.

[0033] Here, if the host end has no alarm reset, the host end is responded as the slave end according to the first handshake flow, so as to establish a communication path between the host end and the slave end, to ensure that data can be normally transmitted between the host end and the slave end.

[0034] In some possible implementation manners, the step 104 can be implemented by Figure 3 The step shown is implemented as follows: 301, if the host end has no alarm reset, a command combination of the slave end is responded based on the first handshake flow.

[0035] Here, if the type of the inter-processor communication message polled is MSG_TYPE_OPEN, it is determined that the alarm reset of the opposite end is not needed, and a command combination from the slave end is responded to according to the first handshake process to establish a communication path between the slave end and the master end.

[0036] In some possible implementation manners, if the master end has no alarm reset, the open command, the open acknowledgement command and the initialization end command of the master end are responded to based on the first handshake process, and the open command, the open acknowledgement command and the initialization end command are determined as the command combination. For example, the command combination includes an OPEN, an OPEN_ACK and an INIT_DONE inter-processor communication message.

[0037] 302. A channel between the master end and the slave end is created based on the command combination.

[0038] Here, the channel between the slave end and the master end is established by responding to the command combination of the master end, so that the slave end and the master end can normally communicate.

[0039] 303. The channel is reset to the first initialization state to obtain a communication path between the master end and the slave end.

[0040] Here, after the channel between the master end and the slave end is established, the information of the channel is reset, and the channel is reset to the first initialization state, so that the channel is the same as the first initialization (INIT) state. In this way, the communication path between the master end and the slave end is re-established, and the transmission of business data is restored, so that the communication path can be restored at the fastest speed after the single-end abnormal reset.

[0041] In the embodiment of the application, after the running states of the master end and the slave end are obtained, the type of the inter-processor communication message is determined in the case that the running state of the master end is an abnormal state and the running state of the slave end is a normal state. In this way, in the case that the master end is hung up but the slave end normally runs, it is determined whether the type of the inter-processor communication message represents that the channel is being opened. If the type of the inter-processor communication message represents that the channel is being opened, it is determined whether the master end has no alarm reset. If the master end has no alarm reset, a communication path between the master end and the slave end is established based on the first handshake process. In this way, when the master end is abnormally reset and cannot notify the slave end to restart, the communication path between the master end and the slave end is re-established and the transmission of business data is restored if the type of the inter-processor communication message represents that the channel is being opened, so that the communication path can be restored at the fastest speed after the single-end abnormal reset.

[0042] In some embodiments, the method for recovering from abnormal state of inter-core communication path can be: Figure 4 The process framework shown is implemented as follows Figure 4 As shown: the client thread (ie, the slave end 41) is in the module (SBUF thread) corresponding to the streaming data transmission thread on the slave end (ie Figure 4 During the SBUF creation (SBUF_CREAT) 43, the inter-core communication message from the host (HOST USER THREAD) is further checked. If the message type is not MSG_TYPE_OPEN, the process continues as normal. The inter-core communication message type is polled by reading the SBUF (SBUF_READ) 44. If the message type is MSG_TYPE_OPEN, the host determines that no alarm resets have occurred (i.e., judging the type, it predicts that no warning resets have occurred on the peer end). Following the initial handshake process, the slave responds to the host's OPEN, OPEN_ACK, and INIT_DONE inter-core communication messages (i.e., the initial handshake process is completed by waiting for the inter-core communication message (MSG_WAIT 45)). The slave's SBUF responds to the channel deinitialization (CHN DEINIT), discarding existing data and resetting the address and pointer (ADDR and PTR) information. This ensures that the host process properly resets the channel information and maintains the channel in the initial INIT state.

[0043] The embodiment of the present invention provides a device for recovering abnormal state of a path of inter-core communication, such as Figure 5 As shown, the device 500 includes: The acquisition module 501 is used to obtain the operating status of the host end and the slave end; A first determining module 502 is configured to determine a type of an inter-core communication message when the operating state of the host end is abnormal and the operating state of the slave end is normal; A second determining module 503 is configured to determine that no alarm has been reset on the host side if the type of the inter-core communication message is a preset type; The establishing module 504 is configured to establish a communication path between the host and the slave based on a first handshake process if there is no alarm reset on the host.

[0044] In some possible implementations, the establishing module 504 is further configured to respond to the command combination of the slave side based on the first handshake process if there is no alarm reset on the host side; Based on the command combination, a channel is created between the host end and the slave end; The channel is reset to an initial initialization state to obtain a communication path between the host end and the slave end.

[0045] In some possible implementation manners, the establishing module 504 is further configured to, if the host end has no alarm reset, respond to an opening command, an opening response command and an initialization end command of the host end based on the first handshake process; The opening command, the opening response command and the initialization end command are determined as the command combination.

[0046] In some possible implementation manners, the first determining module 502 is further configured to, if the running state of the host end is an abnormal state and the running state of the slave end is a normal state, control the host end to actively restart, and determine a streaming data transmission thread of the slave end. In the streaming data transmission thread, the type of the inter-core communication message of the host end is determined.

[0047] In some possible implementation manners, the second determining module 503 is further configured to, if the inter-core communication type is a channel opening type, determine a data transmission mode of the inter-core communication message. If the data transmission mode is message queue data transmission, it is determined that the host end has no alarm reset.

[0048] In some possible implementation manners, the second determining module 503 is further configured to, if the type of the inter-core communication message is a non-pre-set type, perform message type polling on the inter-core communication until the type of the inter-core communication message is a pre-set type.

[0049] In some possible implementation manners, the second determining module 503 is further configured to, if the type of the inter-core communication message is a non-pre-set type, acquire a polling period of the inter-core communication; and if the running state of the host end is an abnormal state and the running state of the slave end is a normal state, perform message type polling on the inter-core communication based on the polling period until the type of the inter-core communication message is a pre-set type.

[0050] In some possible implementation manners, the second determining module 503 is further configured to, if the running state of the host end is an abnormal state and the running state of the slave end is a normal state, poll, based on the polling period, a message queue data transmission module of the inter-core communication of the host end through the slave end to obtain the type of the inter-core communication message.

[0051] Optionally, the transmission medium can be a wired link (for example, but not limited to, a coaxial cable, an optical fiber, a Digital Subscriber Line (DSL), and the like) or a wireless link (for example, but not limited to, Wireless Fidelity (WIFI), Bluetooth, and a mobile device network, and the like). It should be noted that the system provided in the above embodiments is only used as an example for the division of the above functional modules, and in actual applications, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the computer device is divided into different functional modules to complete all or part of the above described functions. In addition, the method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process is shown in the method embodiments, which will not be described here.

[0052] Figure 6 is a structural schematic diagram of a computer device provided by an embodiment of the present application. As shown in the example, Figure 6 the computer device 600 includes a memory 601, a processor 602, and a computer program 603 stored in the memory 601 and running on the processor 602, wherein when the processor 602 executes the computer program 603, the computer device can execute the above-described any one of the inter-core communication path abnormal state recovery methods.

[0053] In addition, an embodiment of the present application also protects a system, which can include a memory and a processor, wherein the memory stores executable program code, and the processor is configured to call and execute the executable program code to execute an inter-core communication path abnormal state recovery method provided by an embodiment of the present application. The present embodiment can divide the system into functional modules according to the above method examples, for example, each functional module can be corresponding, or two or more functions can be integrated in one processing module, and the above integrated module can be realized in the form of hardware. It should be noted that the division of the modules in the present embodiment is illustrative, and is only a logical function division, and another division mode can be used in actual implementation. It should be noted that all related contents of each step involved in the above method embodiments can be cited to the function description of the corresponding functional module, and will not be described here.

[0054] It should be understood that the system provided by the embodiments is used to perform the above-mentioned inter-core communication path abnormal state recovery method, and thus the same effects as the above-mentioned implementation method can be achieved. In the case of using an integrated unit, the system can include a processing module and a storage module. When the system is applied to a device, the processing module can be used to control and manage the actions of the device. The storage module can be used to support the device to execute mutual program codes and the like. The processing module can be a processor or a controller, which can implement or execute various exemplary logical blocks, modules and circuits described in combination with the disclosure. The processor can also be a combination of computing functions, such as one or more microprocessor combinations, a combination of digital signal processing (DSP) and microprocessor, and the like. The storage module can be a memory.

[0055] In addition, the system provided by the embodiments of the present application can be a chip, an assembly or a module, which can include a connected processor and a memory. The memory is used to store instructions, and when the processor calls and executes the instructions, the chip can execute the above-mentioned inter-core communication path abnormal state recovery method provided by the embodiments. The present embodiment also provides a computer readable storage medium, which stores computer program codes. When the computer program codes are run on the computer, the computer can execute the above-mentioned related method steps to implement the above-mentioned inter-core communication path abnormal state recovery method provided by the embodiments.

[0056] The embodiment further provides a computer program product, which, when running on a computer, enables the computer to execute the above related steps to implement the inter-core communication path abnormal state recovery method provided by the above embodiment. The system, computer readable storage medium, computer program product or chip provided by the embodiment are used to execute the corresponding method provided above, and thus the beneficial effects achieved thereby can refer to the beneficial effects of the corresponding method provided above, which will not be described here again. Through the above description of the implementation manner, those skilled in the art can understand that, for the convenience and brevity of description, only the division of the above functional modules is taken as an example for illustration, and in actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the system is divided into different functional modules to complete all or part of the functions described above. In the embodiments provided by the present application, it should be understood that the disclosed system and method can be implemented by other ways. For example, the system embodiments described above are only schematic, for example, the division of the modules or units is only a logical function division, and other division manners can be adopted in actual implementation, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interfaces, and can be electrical, mechanical or other forms.

[0057] It should be noted that the above-mentioned sequence of the embodiments of the present application is only for description, and does not represent the advantages and disadvantages of the embodiments. The processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multiple task processing and parallel processing are also possible or can be advantageous. Each embodiment in the specification is described in a progressive manner, and the same or similar parts of each embodiment can be referred to each other, and each embodiment mainly describes the differences from other embodiments. The above is only a specific implementation manner of the present application, but the protection scope of the present application is not limited to this. Any person skilled in the art can easily think of changes or replacements within the technical range disclosed by the present application, which should be covered within the protection scope of the present application.

Claims

1. A method for recovering from abnormal state of inter-core communication path, characterized in that: The method comprises: Get the running status of the host and slave; When the running state of the host side is abnormal and the running state of the slave side is normal, determining the type of the inter-core communication message; If the type of the inter-core communication message is a preset type, determining whether there is no alarm reset on the host side; If there is no alarm reset on the host side, a communication path is established between the host side and the slave side based on the first handshake process.

2. A method for recovering from abnormal state of inter-core communication path according to claim 1, characterized in that: If the host side does not have an alarm reset, establishing a communication path between the host side and the slave side based on a first handshake process includes: If the host side has no alarm reset, responding to the command combination of the slave side based on the first handshake process; Based on the command combination, a channel is created between the host end and the slave end; The channel is reset to an initial initialization state to obtain a communication path between the host end and the slave end.

3. The method for recovering from abnormal state of inter-core communication path according to claim 2, characterized in that: If the host side has no alarm reset, responding to the command combination of the slave side based on the first handshake process includes: If the host side has no alarm reset, responding to the host side's open command, open response command and initialization end command based on the first handshake process; The open command, the open response command and the initialization end command are determined as the command combination.

4. The method for recovering from abnormal state of inter-core communication path according to claim 1, characterized in that: The determining the type of the inter-core communication message when the running state of the host side is an abnormal state and the running state of the slave side is a normal state includes: When the running state of the host side is abnormal and the running state of the slave side is normal, controlling the host side to actively restart and determining the streaming data transmission thread of the slave side; In the streaming data transmission thread, the type of the inter-core communication message on the host side is determined.

5. The method for recovering from abnormal state of inter-core communication path according to claim 1, characterized in that: If the type of the inter-core communication message is a preset type, determining whether there is no alarm reset on the host side includes: If the inter-core communication type is a channel opening type, determining a data transmission mode for the inter-core communication message; If the data transmission mode is message queue data transmission, determine whether there is no alarm reset on the host side.

6. The method for recovering from abnormal state of inter-core communication path according to claim 1, characterized in that: The method further comprises: If the type of the inter-core communication message is a non-preset type, the inter-core communication is polled for message types until the type of the inter-core communication message is found to be a preset type.

7. The method for recovering from abnormal state of inter-core communication path according to claim 6, characterized in that: If the type of the inter-core communication message is a non-preset type, performing message type polling on the inter-core communication until the type of the inter-core communication message is a preset type, including: If the type of the inter-core communication message is a non-preset type, obtaining a polling period for the inter-core communication; When the running state of the host side is abnormal and the running state of the slave side is normal, the message type of the inter-core communication is polled based on the polling cycle until the type of the inter-core communication message is found to be a preset type.

8. The method for recovering from abnormal state of inter-core communication path according to claim 7, characterized in that: The method further comprises: When the running state of the host side is abnormal and the running state of the slave side is normal, based on the polling cycle, the slave side polls the inter-core communication message queue data transmission module of the host side to obtain the type of the inter-core communication message.

9. A device for recovering from abnormal state of inter-core communication path, characterized in that: The inter-core communication path abnormal state recovery device includes: The acquisition module is used to obtain the operating status of the host and slave ends; A first determining module, configured to determine a type of an inter-core communication message when the operating state of the host end is abnormal and the operating state of the slave end is normal; A second determining module is configured to determine whether the host side has no alarm reset if the type of the inter-core communication message is a preset type; An establishing module is used to establish a communication path between the host end and the slave end based on a first handshake process if there is no alarm reset on the host end.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and when the computer instructions are executed on an electronic device, the electronic device is caused to perform the method according to any one of claims 1 to 8.

Images