Communication failure handling method and electronic device

Abstract

Embodiments of the present application provide a communication fault processing method and an electronic device, the electronic device comprising an AP and an ADSP, there being at least one first QMI channel, a second QMI channel and a third QMI channel between the AP and the ADSP, the method comprising: in the case of a fourth QMI channel communication anomaly, the AP sending a first message to the ADSP via the second QMI channel; the fourth QMI channel being any one of the at least one first QMI channel, the fourth QMI channel being used to transmit data of a first service; if a response of the ADSP to the first message does not time out, the AP sending a second message to the ADSP via the third QMI channel; the second message being used to request a restart of a process corresponding to the first service in the ADSP; if the response of the ADSP to the first message times out, the AP sending a first instruction to the ADSP, the first instruction being used to instruct a restart of a subsystem running in the ADSP. The method uses different restart modes to recover QMI communication according to different faults, prevents an impact on services in the ADSP system that have not failed, and improves user experience.

Description

Technical Field

[0001] This application relates to the field of electronic technology, specifically to a communication fault handling method and an electronic device. Background Technology

[0002] Qualcomm Messaging Interface (QMI) is a message communication mechanism for inter-process communication in multiprocessors. QMI is widely used in electronic devices for communication between application processors (APs) and subsystem processors, as well as between subsystem processors. One example is QMI communication between an AP and an application digital signal processor (ADSP).

[0003] There are numerous QMI channels between the AP and ADSP for various service data exchanges, such as sensor data exchange, audio data exchange, and power data exchange. Therefore, timely restoration of communication when QMI channel communication is interrupted is crucial for the normal operation of electronic devices.

[0004] In traditional technology, if communication on a QMI channel between the AP and ADSP is interrupted, the ADSP subsystem is restarted to restore QMI channel communication. However, this method affects all services within the ADSP subsystem, impacting user experience. Summary of the Invention

[0005] This application provides a communication fault handling method and electronic device, which can detect the fault status of the QMI communication function of ADSP. Different faults are handled by different restart methods to restore QMI communication. While restoring communication, the method prevents the impact on services in the ADSP system that have not experienced faults, thereby improving the user experience.

[0006] In a first aspect, this application provides a communication fault handling method, which is executed by an electronic device including an application processor (AP) and an application digital signal processor (ADSP). At least one first QMI channel for transmitting services exists between the AP and the ADSP. A second QMI channel and a third QMI channel also exist between the kernel layer of the AP and the ADSP. The method includes: in the event of a communication failure on a fourth QMI channel, the AP sends a first message to the ADSP through the second QMI channel; the fourth QMI channel is any one of the at least one first QMI channel, and the fourth QMI channel is used to transmit data for the first service; if the ADSP's response to the first message does not time out, the AP sends a second message to the ADSP through the third QMI channel; the second message is used to request the restart of the process corresponding to the first service in the ADSP; if the ADSP's response to the first message times out, the AP sends a first instruction to the ADSP, the first instruction being used to instruct the restart of the subsystem running in the ADSP.

[0007] The first QMI channel is also known as the business QMI channel. The second QMI channel is also known as the fault detection QMI channel. The third QMI channel is also known as the process restart QMI channel.

[0008] The fourth QMI channel is, for example, a sensor QMI channel. The first message can be a detection broadcast message in a specific embodiment. The second message can be a process restart request message in a specific embodiment. The first instruction can be a subsystem restart instruction in a specific embodiment.

[0009] The communication fault handling method provided in the first aspect of this application involves the AP sending a first message to the ADSP via the second QMI channel when the fourth QMI channel communication is abnormal. Based on the ADSP's response to the first message, the system-level QMI communication function of the ADSP is determined to be normal. Since the second QMI channel is the channel between the AP and the ADSP's kernel layer, if the ADSP's response to the first message does not time out, it indicates that the ADSP's system-level QMI communication function is normal. The problem may be caused by a fault in the process corresponding to the first service running in the ADSP, leading to the abnormality in the fourth QMI communication function. Therefore, restarting the process corresponding to the first service in the ADSP restores the communication of the fourth QMI channel, preventing impact on other processes in the ADSP, preventing impact on other services, and thus preventing impact on user experience. If the ADSP's response to the first message times out, it indicates that the ADSP's system-level QMI communication function is abnormal. Restarting the ADSP subsystem restores the system-level QMI communication function. This not only restores the communication of the currently faulty QMI channel (i.e., the fourth QMI channel) but also restores the communication of other QMI channels, preventing other service failures and further improving the user experience.

[0010] In one possible implementation, if the ADSP's response to the first message does not time out, before the AP sends the second message to the ADSP through the third QMI channel, the method further includes: if the AP receives a third message sent by the ADSP through the second QMI channel within a first preset time after sending the first message, then it is determined that the ADSP's response to the first message has not timed out; the third message is used to respond to the first message; if the AP does not receive a third message sent by the ADSP through the second QMI channel within the first preset time after sending the first message, then the AP determines whether the number of times the first message has been sent is equal to the first number threshold; if the number of times the first message has been sent is equal to the first number threshold, then it is determined that the ADSP's response to the first message has timed out; if the number of times the first message has been sent is less than the first number threshold, then the execution step is returned: the AP sends the first message to the ADSP through the second QMI channel.

[0011] Optionally, the third message can be the detection completion request message in the specific embodiment. The first preset duration can be the preset duration t2 in the specific embodiment. The first count threshold can be the preset count threshold N2 in the specific embodiment.

[0012] In this implementation, a system-level QMI communication function of the ADSP is considered abnormal only if the ADSP fails to respond within a preset time period after sending multiple first messages (i.e., detection broadcast messages). This prevents individual message sending anomalies from being identified as system-level QMI communication function anomalies, improving the accuracy of fault diagnosis, thereby improving the accuracy of restart method selection and enhancing user experience.

[0013] In one possible implementation, during communication based on the second QMI channel, the AP acts as the server and the ADSP acts as the client.

[0014] In this implementation, considering that the ADSP subsystem is less stable than the main system on the AP side, and is more prone to failure leading to restarts or power outages, if the ADSP is used as the QMI communication server and the AP as the QMI communication client, the AP cannot be notified of ADSP subsystem restarts or power outages in a timely manner. Consequently, the AP cannot register its port with the ADSP in a timely manner, and therefore cannot promptly restore the second QMI channel (i.e., the fault detection QMI channel). Therefore, using the AP as the communication server and the ADSP as the communication client can prevent the second QMI channel from failing to restore in a timely manner.

[0015] In one possible implementation, the first message is a broadcast notification message, and the second and third messages are both request messages.

[0016] In this implementation, the first message is a broadcast notification message, and the second and third messages are request messages. This matches the CS structure where "AP acts as the communication server and ADSP acts as the communication client," enabling normal message transmission.

[0017] In one possible implementation, the method further includes: if the AP receives a third message sent by the ADSP through the second QMI channel within a first preset time after sending the first message, the AP sends a fourth message to the ADSP, the fourth message being a response message to the third message.

[0018] The fourth message can be the detection completion response message in a specific embodiment.

[0019] In one possible implementation, before the AP sends the first message to the ADSP via the second QMI channel, the method further includes: in response to the ADSP powering on, the ADSP sends a registration request message to the AP, the registration request message being used to request registration port information.

[0020] In this implementation, the AP acts as the server for the second QMI channel communication, and the ADSP acts as the client. When the ADSP powers on, it sends a registration request message to the AP to register the port, thus establishing the second QMI channel between the AP and the ADSP. In other words, after a restart or power failure, the ADSP's re-power-on triggers the registration of the communication port with the AP. This allows the ADSP to promptly re-establish second QMI communication with the AP, improving the reliability of fault detection QMI communication.

[0021] In one possible implementation, after the AP sends the second message to the ADSP through the third QMI channel, the method further includes: if the AP does not receive the fifth message sent by the ADSP through the third QMI channel within a second preset time period after sending the second message, the AP sends a first instruction to the ADSP; the fifth message is a response message to the second message.

[0022] The second preset duration can be the preset duration t3 in the specific embodiment. The fifth message can be the process restart response message in the specific embodiment.

[0023] In this implementation, the restart status of the process is determined by monitoring the ADSP's response to the second message (i.e., the process restart request message). If the AP does not receive the fifth message (i.e., the process restart response message) from the ADSP within a second preset time period, it indicates that the process restart has failed. In the event of a process restart failure, the AP further sends a first instruction (i.e., the subsystem restart instruction) to the ADSP to control the restart of the ADSP subsystem, further ensuring the reliability of the QMI communication function.

[0024] In one possible implementation, a first Glink channel exists between the kernel layer of the AP and the ADSP. The AP sends a first instruction to the ADSP, including: the AP sends a first instruction to the ADSP through the first Glink channel; after the AP sends the first instruction to the ADSP, the method further includes: after the subsystem running in the ADSP restarts successfully, the ADSP sends a first signal to the AP through the first Glink channel.

[0025] The first signal can be a subsystem restart signal in a specific embodiment.

[0026] When the ADSP's system-level QMI communication function malfunctions, the ADSP subsystem needs to be restarted. Since the system-level QMI communication function malfunctions and the first restart command cannot be sent via the QMI channel, this implementation method sends the first command via the Glink channel. This ensures that the first command is accurately and promptly transmitted to the ADSP, thereby controlling the ADSP to restart in a timely manner and restore QMI communication.

[0027] In one possible implementation, in the event of a communication failure in the fourth QMI channel, before the AP sends the first message to the ADSP via the second QMI channel, the method further includes: the AP sending a sixth message to the AP via the fourth QMI channel; the sixth message is used to request data for the first service; if the AP does not receive a seventh message sent by the ADSP via the fourth QMI channel within a third preset time period after sending the sixth message, it is determined that the fourth QMI channel communication is normal; the seventh message is a response message to the sixth message; if the AP does not receive a seventh message sent by the ADSP via the fourth QMI channel within a third preset time period after sending the sixth message, it is determined whether the number of times the sixth message has been sent is equal to the second threshold; if the number of times the sixth message has been sent is equal to the second threshold, it is determined that the fourth QMI channel communication is abnormal; if the number of times the sixth message has been sent is less than the second threshold, the execution step is returned: the AP sends the sixth message to the AP via the fourth QMI channel.

[0028] The sixth message can be a data request message in a specific embodiment. The seventh message can be a data response message in a specific embodiment. The second count threshold can be a preset count threshold N1 in a specific embodiment.

[0029] In this implementation, the status of the fourth QMI channel communication is determined by sending a sixth message (i.e., a data request message) to the ADSP multiple times. Only if no response is received from the ADSP within a second preset time period after multiple sixth message transmissions is the QMI channel communication considered abnormal. This prevents individual message transmission anomalies from being attributed to a fourth QMI channel anomaly, improving the accuracy of QMI communication status assessment.

[0030] In one possible implementation, the first QMI channel is used to transmit sensor service data, audio service data, or charging service data.

[0031] Secondly, this application provides an apparatus included in an electronic device, which has the function of implementing the behaviors of the electronic device in the first aspect and possible implementations thereof. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above-described functions. For example, a receiving module or unit, a processing module or unit, etc.

[0032] Thirdly, this application provides an electronic device comprising: a plurality of processors and a memory; the plurality of processors including an application processor (AP) and an application digital signal processor (ADSP); the memory is coupled to the plurality of processors and is used to store computer program code, the computer program code including computer instructions, wherein the plurality of processors invoke the computer instructions to cause the electronic device to execute any method of the technical solution in the first aspect.

[0033] Fourthly, this application provides a chip system applied to an electronic device. The chip system includes multiple processors, including an application processor (AP) and an application digital signal processor (ADSP). The multiple processors are used to invoke computer instructions to cause the electronic device to perform the methods in the first aspect and any possible implementation thereof.

[0034] Optionally, the chip system may also include memory, which is connected to the processor via circuitry or wires.

[0035] Alternatively, the chip system may also include a communication interface.

[0036] Fifthly, this application provides a computer-readable storage medium including instructions that, when executed on an electronic device, cause the electronic device to perform any one of the methods in the first aspect of the technical solution.

[0037] Sixthly, this application provides a computer program product, which includes computer program code that, when executed on an electronic device, causes the electronic device to perform any one of the methods in the first aspect of the technical solution. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0039] Figure 2 This is a system architecture block diagram of an example electronic device provided in an embodiment of this application;

[0040] Figure 3 This is a schematic diagram illustrating the relationship between the root process and other processes in an ADSP subsystem provided in an embodiment of this application.

[0041] Figure 4 This is a schematic diagram of a communication channel between the AP side and the ADSP subsystem provided in an embodiment of this application;

[0042] Figure 5 This is a schematic diagram of a process for establishing a fault detection QMI channel provided in an embodiment of this application;

[0043] Figure 6 This is a flowchart illustrating an example of a communication fault handling method provided in an embodiment of this application;

[0044] Figure 7-1 This is one of the flowcharts illustrating another communication fault handling method provided in the embodiments of this application;

[0045] Figure 7-2 This is a second schematic flowchart of another communication fault handling method provided in the embodiments of this application;

[0046] Figure 8 This is a flowchart illustrating yet another communication fault handling method provided in the embodiments of this application;

[0047] Figure 9 This is a flowchart illustrating yet another communication fault handling method provided in the embodiments of this application;

[0048] Figure 10 This is a flowchart illustrating another communication fault handling method provided in the embodiments of this application. Detailed Implementation

[0049] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0050] Hereinafter, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include one or more of that feature.

[0051] References to "one embodiment" or "some embodiments" as described in this application specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this application specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0052] To better understand the embodiments of this application, the terms or concepts that may be involved in the embodiments are explained below.

[0053] 1. Processor and Subsystem

[0054] Electronic devices may include multiple processors, such as APs, modems, ADSPs and computational digital signal processors (CDSPs), baseband processors, wireless local area network (WLAN) processors, etc.

[0055] The operating system of an electronic device may include a main system running on the AP side (hereinafter referred to as the AP side) and one or more subsystems running on other processors. These one or more subsystems may include, but are not limited to, a subsystem running on an ADSP (ADSP subsystem), a subsystem running on a CDSP (CDSP subsystem), a subsystem running on a modem (modem subsystem), and a subsystem running on a WLAN processor (WLAN subsystem). The ADSP subsystem can be used to implement functions such as audio processing, sensor data acquisition, and charging management (e.g., battery statistics). The CDSP subsystem can be used to implement functions such as image signal processing and encoding / decoding. The WLAN subsystem is used to implement data processing and transmission during wireless communication.

[0056] 2. QMI communication

[0057] QMI communication is primarily used for inter-core communication between the AP and communication processors (CP), ADSPs, and computational digital signal processors (CDSPs). QMI transmits data through shared memory drivers, implementing physical operations of shared memory and providing multiple data channels for message passing. QMI adopts a client-server architecture (CS), where one server can serve multiple clients simultaneously. In the code, clients typically register with the server and send requests to the server to obtain certain data or perform certain operations.

[0058] QMI message types mainly include:

[0059] Request message: The client sends a request to the server.

[0060] Response message: The server sends a response message to the client after receiving a request.

[0061] Broadcast notification message: The server proactively broadcasts a notification message to all clients.

[0062] 3. System-level QMI communication function and service-level QMI communication function

[0063] It is understood that the ADSP subsystem can establish one or more QMI channels with the AP side. The QMI channel used for transmitting service data is called the service QMI channel (also known as the first QMI channel). In this embodiment, the QMI channel used for sensor data transmission is called the sensor QMI channel (also known as the fourth QMI channel), the QMI channel used for audio data transmission is called the audio QMI channel, and the QMI channel used for charging data transmission is called the charging QMI channel.

[0064] The ADSP subsystem has the function of supporting and managing communication of all QMI channels, which is called the system-level QMI communication function. The system-level QMI communication function can also be understood as the overall QMI communication function of the ADSP subsystem. When the system-level QMI communication function malfunctions, communication of all QMI channels in the ADSP subsystem is interrupted.

[0065] Service-level QMI communication function refers to the communication function of one or more service QMI channels in the ADSP subsystem. A service-level QMI communication function malfunction means that this one or more service QMI channels cannot communicate, while other QMI channels may communicate normally.

[0066] 4. Glink (general link) communication

[0067] Glink communication is a multi-layered communication protocol framework primarily used for communication between various intellectual property cores (IP cores) within a system on-chip (SoC), such as communication between the ARM core of an application processor (AP) and a CDSP or ADSP. Glink communication is a point-to-point communication method.

[0068] Each subsystem in an electronic device needs to interact with the AP (Access Point) during operation to achieve its respective functions. This application primarily relates to the interaction between the AP and the ADSP (Automatic Data Processing) subsystem. QMI (Quality Management Interface) is a crucial communication mechanism in this interaction. Numerous QMI channels exist between the AP and the ADSP subsystem, each capable of handling different service data interactions. Therefore, the proper functioning of the QMI channels is critical for the normal operation of AP-side services. Several scenarios illustrating QMI channel-based communication between the AP and the ADSP subsystem are listed below:

[0069] 1. Sensor data interaction scenarios

[0070] Some applications on the AP side need to acquire sensor data during operation, such as sports and health applications and Applications need to acquire acceleration data, gyroscope data, etc., to determine the state of electronic devices and count steps; for example, photo album applications need to acquire gravity sensor data and acceleration data to determine whether the electronic device is being rotated, thereby enabling the screen to rotate automatically.

[0071] When the AP side needs to acquire sensor data, it can send a sensor data acquisition request to the ADSP subsystem via the sensor QMI channel. Upon receiving the request, the ADSP subsystem reads the sensor data, such as data from the accelerometer and gyroscope. The ADSP subsystem then returns the sensor data to the AP side via the sensor QMI channel. If the sensor QMI channel communication is interrupted, the AP side cannot send a sensor data acquisition request to the ADSP subsystem, or the ADSP subsystem cannot return the sensor data to the AP side. This will cause anomalies in the AP side's application, such as failure to update motion data or inability to rotate the screen, impacting the user experience.

[0072] 2. Audio data interaction scenarios

[0073] When an audio playback application on the AP side plays audio, it requires the ADSP subsystem to process the audio data, such as decoding it. In this case, the AP side transmits audio data to the ADSP subsystem via the audio QMI channel. After decoding the audio data, the ADSP subsystem sends the decoded data back to the AP side via the audio QMI channel. If the audio QMI channel communication is interrupted, the AP side cannot send audio data to the ADSP subsystem, or the ADSP subsystem cannot send the decoded data to the AP side. This will cause the audio playback application on the AP side to experience intermittent audio playback or silence, negatively impacting the user experience.

[0074] 3. Battery data interaction scenarios

[0075] During use or charging, the ADSP subsystem can monitor the battery level and send this data to the AP (Access Point) via the charging QMI channel. The AP then updates the battery information on the user interface and controls the start and stop of charging based on this data. In a non-charging scenario, if the charging QMI channel communication is interrupted, the ADSP subsystem cannot send battery data to the AP, and the AP cannot update the battery information on the interface. This results in the battery level remaining unchanged for the user, failing to alert them to charging, and ultimately causing the electronic device to run out of power without their knowledge, rendering it unable to power on and impacting the user experience. Furthermore, during charging, if the charging QMI channel communication is interrupted, the ADSP subsystem cannot send battery data to the AP, and the AP cannot control the start of charging, causing the electronic device to shut down due to depletion of power, or it cannot control the stop of charging, leading to overcharging and battery damage.

[0076] Therefore, the reliability of QMI channel communication between the AP side and the ADSP subsystem is crucial. However, in practical applications, QMI channel communication interruptions are inevitable. Thus, knowing how to promptly restore communication during such interruptions is also critical.

[0077] In related technologies, when QMI channel communication is interrupted, communication is typically restored by restarting the ADSP subsystem. However, an interruption in the QMI channel communication of a specific service triggers a restart of the entire ADSP subsystem. While communication is restored, this impacts other services. For example, a restart of the ADSP subsystem due to an interruption in the QMI channel for sensor data would also affect audio and charging services, impacting user experience.

[0078] To address this issue, this application provides a communication fault handling method. By establishing a QMI detection channel and a process restart channel between the AP side and the ADSP subsystem, when the QMI channel communication for a certain service is interrupted, the AP side sends a detection broadcast message (also called the first message) to the root process of the kernel layer in the ADSP subsystem through the QMI detection channel. If the AP side can normally receive the response from the ADSP subsystem to the detection broadcast message, it indicates that the system-level QMI communication function of the ADSP subsystem is normal. However, the abnormality in the service-level QMI communication function may be caused by a process domain (PD, hereinafter referred to as process) fault in the ADSP subsystem. Therefore, the AP side sends a process restart request message (also called the second message) to the ADSP subsystem through the process restart channel, requesting the restart of the service process to restore the communication of the service's QMI channel. If the ADSP subsystem's response to the detection broadcast message times out, it indicates that the system-level QMI communication function of the ADSP subsystem is abnormal. Therefore, a subsystem restart instruction (also called the first instruction) is sent to the ADSP subsystem, instructing the restart of the entire ADSP subsystem to restore the system-level QMI communication function. In this way, QMI communication function faults in the ADSP subsystem are detected through the QMI detection channel. Different restart methods are used to restore QMI communication for different faults. While restoring communication, it is possible to prevent the impact on services in the ADSP system that have not experienced faults, thereby improving the user experience.

[0079] The communication fault handling method provided in this application embodiment can be applied to electronic devices with ADSP subsystems, such as mobile phones, tablets, wearable devices, vehicle-mounted devices, augmented reality (AR) / virtual reality (VR) devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, and personal digital assistants (PDAs). This application embodiment does not impose any restrictions on the specific type of electronic device.

[0080] For example, Figure 1This is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of this application. The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0081] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0082] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, ADSP, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0083] The charging management module 140 receives charging input from the charger. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141. Optionally, during the charging process, the charging management module 140 can provide power data via the ADSP.

[0084] The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, providing power to the processor 110, internal memory 121, external memory, display screen 194, camera 193, and wireless communication module 160. The power management module 141 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). Battery capacity is also known as power data, which can be obtained through ADSP statistics. In some other embodiments, the power management module 141 may also be located within the processor 110, for example, within the ADSP. In other embodiments, the power management module 141 and the charging management module 140 may be housed in the same device.

[0085] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0086] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 can be located in the processor 110, or some functional modules of the audio module 170 can be located in the processor 110. For example, the encoding and decoding functions of the audio module 170 can be located in an ADSP.

[0087] Some or all of the sensors in sensor module 180 can be connected to ADSP, which can acquire sensor data and transmit it to AP via QMI channel.

[0088] The software architecture of electronic device 100 will be described below.

[0089] Figure 2 This is a system architecture block diagram of an electronic device 100 according to an embodiment of this application. Figure 2 As shown, the software system of electronic device 100 may include a main system running on the AP side and a subsystem running on the ADSP. Additionally, for ease of explanation, Figure 2 The hardware layer 200 of the electronic device 100 is also shown.

[0090] First, let me explain the architecture of the AP-side main system.

[0091] The main system running on the AP can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application uses a layered architecture Android system as an example for illustration.

[0092] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into five layers, from top to bottom: the application layer 210, the application framework layer 220, the hardware abstraction layer 230, and the kernel layer 240.

[0093] Application layer 210 may include a series of application packages. For example... Figure 2 As shown, the application package can include applications such as fitness and health, music, and gallery. Of course, application layer 210 can also include applications such as camera, calendar, call, map, navigation, WLAN, Bluetooth, video, and SMS. Figure 2 Not shown in the image.

[0094] Application framework layer 220 provides application programming interface (API) and programming framework for the applications of application layer 210. The application framework layer includes some predefined functions.

[0095] like Figure 2 As shown, the application framework layer 220 may include a sensor service, an audio service, and a charging service. The sensor service provides sensor data and related services to upper layers (such as the application layer 210). The audio service provides audio processing services to upper layers. The charging service provides charging-related data and services, such as battery level data, to upper layers.

[0096] Additionally, the application framework layer 220 may also include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc. Figure 2 Not shown in the image.

[0097] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0098] Content providers store and retrieve data, making that data accessible to applications. This data can include videos, images, audio, phone calls made and received, browsing history and bookmarks, phone books, and more.

[0099] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0100] The phone manager is used to provide communication functions for electronic device 100. For example, it manages call status (including connection and disconnection).

[0101] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0102] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0103] The hardware abstraction layer (HAL) 230 is used to abstract and encapsulate the hardware functions provided by electronic devices. For example... Figure 2 As shown, the hardware abstraction layer may include a sensor hardware abstraction layer (HAL), an audio hardware abstraction layer (HAL), and a charging hardware abstraction layer (HAL).

[0104] Kernel layer 240, also known as the kernel driver layer, is the layer between hardware and software. For example... Figure 2 As shown, kernel layer 240 may include a fault detection module, a process restart control module, and a subsystem restart control module.

[0105] The sensor hardware abstraction layer, also known as the sensor service processing module, provides a unified sensor data interface to the upper layer (such as the application framework layer 220) to provide sensor data and related services. The audio hardware abstraction layer, also known as the audio service processing module, provides a unified audio data interface to the upper layer to provide audio processing services. The charging hardware abstraction layer, also known as the charging service processing module, provides a unified charging control interface to the upper layer to provide charging-related data and services, including power data. In this embodiment, the sensor hardware abstraction layer, audio hardware abstraction layer, and charging hardware abstraction layer may all have communication fault handling capabilities. The communication fault handling function includes: when the service QMI channel communication with the ADSP subsystem is abnormal, calling the fault detection module of kernel layer 240 to send a detection broadcast message to the ADSP subsystem; determining whether the system-level QMI communication function of the ADSP subsystem is abnormal based on the ADSP subsystem's response to the detection broadcast message; if the system-level QMI communication function of the ADSP subsystem is normal, calling the process restart control module to control the restart of the corresponding service process in the ADSP subsystem; if the system-level QMI communication function of the ADSP subsystem is abnormal, calling the subsystem restart control module to control the restart of the ADSP subsystem; and, in the case that the process restart of the ADSP subsystem fails, calling the subsystem restart control module to control the restart of the ADSP subsystem.

[0106] The fault detection module, also known as the QMI health check (QMI_HEALTH_CHECK) server module, is used to send detection broadcast messages to the ADSP subsystem to check whether the system-level QMI communication function is normal.

[0107] The process restart control module, also known as the service registration QMI notifier client module, is used to send process restart request messages to the ADSP subsystem. The restart request message is used to request the ADSP subsystem to restart the process.

[0108] The subsystem restart control module, also known as the sysmon_sleepmon_glink module, is used to send subsystem restart commands to the ADSP. The subsystem restart commands are used to instruct the ADSP subsystem to restart.

[0109] Of course, kernel layer 240 also includes display drivers, camera drivers, audio drivers, etc. Figure 2 As shown in the image.

[0110] The architecture of the ADSP subsystem is described below.

[0111] In one embodiment, the subsystem running on the ADSP can be a real-time operating system (RTOS). The RTOS can also adopt a layered architecture. Specifically, the RTOS can include, from top to bottom, an application layer 250, a middleware layer 260, a kernel layer 270, and a driver layer 280.

[0112] Application layer 250 can include real-time applications and non-real-time applications. Real-time applications refer to real-time tasks running on an RTOS, such as applications in industrial control, aerospace, and medical devices. These applications have strict time requirements and need to complete tasks within a specified time. Non-real-time applications refer to applications with less stringent time requirements, such as data logging, system monitoring, and remote management.

[0113] Middleware layer 260 may include audio processing middleware, sensor processing middleware, and charging processing middleware, etc. Audio processing middleware provides audio signal processing functions, such as audio encoding, decoding, filtering, and mixing. Audio processing middleware can work in conjunction with audio codecs in hardware layer 200 to achieve high-quality audio processing.

[0114] The sensor processing middleware is used to acquire sensor data from sensors in hardware layer 200 and to process and analyze the acquired sensor data. This includes functions such as data filtering, data fusion, and feature extraction. The sensor processing middleware can improve the quality and availability of sensor data, providing more valuable sensor information for upper-layer applications and the AP side.

[0115] The charging middleware is used to collect power data through the fuel gauge in hardware layer 200, and to analyze and process the power data. The charging middleware can provide accurate power data to upper-layer applications and the AP side.

[0116] The kernel layer 270 is used to implement task scheduling, interrupt handling, memory management, synchronization, and communication in the ADSP subsystem. In this embodiment, the kernel layer 270 includes a detection and response module, a process restart module, and a subsystem restart module.

[0117] The detection response module, also known as the QMI Health Detection (QMI_HEALTH_CHECK) client module, is used to respond to detection broadcast messages sent by the AP side.

[0118] The process restart module, also known as the service registration QMI notifier (servreg QMI notifier) ​​server module, is used to restart the process after receiving a process restart request message from the AP side, and return a process restart response message to the AP side. The process restart response message is used to indicate that the process restart was successful.

[0119] The subsystem restart module, also known as the ADSP_sleepmon module, is used to restart the ADSP subsystem after receiving the subsystem restart command sent by the AP side, and return a subsystem restart signal (i.e., ADSP restart signal) to the AP side. The subsystem restart signal is used to indicate that the ADSP subsystem restart was successful.

[0120] The driver layer 280 provides drivers for various hardware devices in the ADSP subsystem, enabling access and control of the hardware. Driver layer 280 may include sensor drivers, audio codec drivers, fuel gauge drivers, etc.

[0121] See Figure 2 The hardware layer 200 may include hardware devices such as sensors, audio codecs, and fuel gauges. Among them, the sensors may include one or more of the following: pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, and gravity sensors.

[0122] For ease of understanding, the following embodiments of this application will be described using the following methods: Figure 1 and Figure 2 Taking the electronic device with the structure shown as an example, and in conjunction with the accompanying drawings and application scenarios, the communication fault handling method provided in the embodiments of this application will be specifically described.

[0123] First, let's explain the processes running in the ADSP subsystem. The ADSP subsystem implements various functions through processes. Specifically, to achieve sensor data acquisition, the ADSP subsystem can create and run a sensor process (PD). Sensor processing middleware, sensor drivers, and other modules can run within the sensor process to perform sensor data acquisition and processing. For audio processing, the ADSP subsystem can create and run an audio process (audio PD). Audio processing middleware, audio codec drivers, and other modules can run within the audio process to perform audio processing. To achieve charging data (e.g., battery level) statistics, the ADSP can create and run a charger process (charger PD). Charging processing middleware, fuel gauges, and other modules can run within the charger process to perform charging data statistics. Additionally, the ADSP subsystem also runs a root process (root PD). The root process runs at the kernel layer of the ADSP subsystem.

[0124] For example, Figure 3The diagram illustrates the relationship between the root process and other processes in the ADSP subsystem. It shows that the root process can interact with the sensor, audio, and charger processes, respectively, and thus can control and manage these processes, including their creation, termination, and restart. Furthermore, the root process can also control its own restart, thereby restarting the ADSP subsystem.

[0125] Next, the communication channel involved in the method provided in the embodiments of this application will be described. For example, Figure 4 This is a schematic diagram of an example of a QMI communication channel between the AP side and the ADSP subsystem provided in an embodiment of this application. Figure 4 As shown, the service QMI channels between the AP side and the ADSP subsystem include a sensor QMI channel, an audio QMI channel, and a charging QMI channel. Specifically, a sensor QMI channel is established between the sensor hardware abstraction layer on the AP side and the sensor processing middleware in the ADSP subsystem. An audio QMI channel is established between the audio hardware abstraction layer on the AP side and the audio processing middleware in the ADSP subsystem. A charging QMI channel is established between the charging hardware abstraction layer on the AP side and the charging processing middleware in the ADSP subsystem. It can be understood that in communication based on the service QMI channels, the modules on the AP side can act as clients, and the modules in the ADSP subsystem can act as servers. For example, in communication based on the sensor QMI channels, the sensor hardware abstraction layer on the AP side acts as the client, and the sensor processing middleware in the ADSP subsystem acts as the server.

[0126] See also Figure 4 In this embodiment, the fault detection module on the AP side establishes a QMI channel with the detection response module in the ADSP subsystem for transmitting fault detection-related messages. This channel is called the fault detection QMI channel, also known as the QMI health check (QMI_HEALTH_CHECK) channel or the second QMI channel. During communication based on the fault detection QMI channel, the fault detection module on the AP side acts as the server, and the detection response module on the ADSP side acts as the client.

[0127] It's important to note that the detection and response module runs as the root process within the ADSP subsystem's kernel layer. Therefore, the QMI detection channel is the communication channel between the AP side and the root process of the ADSP subsystem. Thus, if the fault detection QMI channel can communicate normally, it indicates that the QMI communication of the ADSP subsystem's root process is normal, meaning the system-level QMI communication function is normal. The problem might be a fault in a process within the ADSP subsystem causing an anomaly in the service-level QMI communication function. Conversely, if the fault detection QMI channel cannot communicate normally, it indicates an anomaly in the QMI communication of the ADSP subsystem's root process, meaning the system-level QMI communication function is abnormal. This could indicate a subsystem freeze or a QMI function hang in the subsystem.

[0128] See also Figure 4 The process restart control module on the AP side establishes a QMI channel with the process restart module in the ADSP subsystem for transmitting relevant messages about process restarts. This channel is called the process restart QMI channel, also known as the servreg QMI notifier channel or the third QMI channel. In communication via this process restart QMI channel, the AP-side process restart control module acts as the client, and the ADSP-side process restart module acts as the server. The process restart module runs as the root process in the kernel layer of the ADSP subsystem; therefore, it can control the restart of other processes within the ADSP subsystem.

[0129] See also Figure 4 The subsystem restart control module on the AP side establishes a Glink channel with the subsystem restart module in the ADSP subsystem for transmitting relevant messages about subsystem restarts. This channel is called the subsystem restart Glink channel, also known as the sysmon_sleepmon_glink channel. The subsystem restart module runs as the root process in the kernel layer of the ADSP subsystem. Therefore, the subsystem restart module can control the restart of the root process, thereby controlling the restart of the ADSP subsystem.

[0130] The following describes the establishment process of the fault detection QMI channel, the process restart QMI channel, and the subsystem restart Glink channel.

[0131] 1) Fault detection QMI channel

[0132] Considering the lower stability of the ADSP subsystem compared to the main system on the AP side, the ADSP subsystem is more prone to failures leading to restarts or power outages. If the ADSP subsystem acts as the server for QMI communication and the AP acts as the client, the AP cannot promptly detect ADSP subsystem restarts or power outages. Consequently, the AP cannot register its port with the ADSP subsystem in a timely manner, thus hindering the timely restoration of the fault detection QMI channel. Therefore, in this embodiment, during fault detection QMI channel communication, the AP acts as the server and the ADSP subsystem as the client. Upon power-on of the ADSP, the ADSP subsystem registers its port with the AP, establishing a fault detection QMI channel. In other words, after a restart or power outage, the ADSP subsystem re-powers on, triggering port registration with the AP. This allows the ADSP subsystem to promptly re-establish fault detection QMI communication with the AP, improving the reliability of the fault detection QMI communication.

[0133] For example, Figure 5 A flowchart illustrating an example of establishing a fault detection QMI channel is provided in this application embodiment, as follows: Figure 5 As shown, the process includes:

[0134] S101. In response to the power-on of the ADSP, the detection and response module in the ADSP subsystem sends a registration request message to the fault detection module on the AP side.

[0135] The registration request message is used to request the registration of a QMI communication port. Optionally, the port registration request may include the port information corresponding to the detection response module.

[0136] Optionally, the registration request message can be represented as hcheck_register_req_msg, where hcheck represents health check, register represents registration, and req_msg represents request message.

[0137] S102, the fault detection module on the AP side responds to the registration request message, registering the port information corresponding to the detection response module.

[0138] S103, the fault detection module on the AP side sends a response message (referred to as the registration response message) to the detection response module in the ADSP subsystem in response to the registration request message.

[0139] Optionally, the registration response message can be represented as hcheck_register_resp_msg, where resp_msg represents the response message.

[0140] At this point, the fault detection module on the AP side and the detection response module in the ADSP subsystem establish a QMI channel.

[0141] 2) Restart the process via QMI channel

[0142] The process restart QMI channel is primarily used by the AP to send process restart request messages to the ADSP subsystem, and by the ADSP subsystem to send process restart response messages to the AP. During communication via the process restart QMI channel, the AP acts as the client, and the ADSP subsystem acts as the server. After the electronic device is powered on and the process restart QMI channel is established between the AP and the ADSP subsystem, the server is unique and fixed for the AP as the client of this channel. Therefore, even if the ADSP subsystem malfunctions, causing a restart or power outage, and the ADSP subsystem has not registered its port with the AP, the AP can still obtain information about the ADSP subsystem. Therefore, the registration process for the relevant ports of the process restart QMI channel will not be described in detail here.

[0143] 3) Restart the Glink channel in the subsystem

[0144] The subsystem restarts the Glink channel, which is not part of the CS architecture and therefore does not require port registration. After the ADSP subsystem restarts or loses power, when the ADSP is powered on again, the ADSP subsystem initializes the subsystem restart Glink channel, including: determining communication parameters, configuring communication ports and addresses, and re-establishing a connection and handshake with the AP side. After that, resource allocation and initialization are performed, and the subsystem restart Glink channel can be re-established.

[0145] The implementation flow of the communication fault handling method provided in this application embodiment is described below. When a certain service QMI channel communication is abnormal in an electronic device, this method detects the system-level QMI communication function of the ADSP subsystem. Based on the detection result, it controls the process in the ADSP subsystem to restart or controls the ADSP subsystem to restart. For ease of explanation, the following description uses a sensor QMI channel communication abnormality as an example. It can be understood that the handling process for audio QMI channel communication abnormalities or charging QMI channel communication abnormalities is similar to the following process.

[0146] For example, Figure 6 This is a flowchart illustrating a communication fault handling method provided in an embodiment of this application. When an application (e.g., a sports and health application) needs to acquire sensor data, the AP side can execute steps S201 to S209, where steps S201 to S203 belong to the data acquisition process, and steps S204 to S209 belong to the fault handling process. Figure 6 As shown, the method includes:

[0147] S201, the AP side sends a data request message (also known as the sixth message) to the ADSP subsystem through the sensor QMI channel (also known as the fourth QMI channel).

[0148] Data request messages are used to request sensor data. Optionally, the data request message may carry information about the type of sensor data requested. For example, in a fitness and health application that requires gyroscope and acceleration data, the data request may include relevant information about the gyroscope and acceleration data.

[0149] S202, the AP side determines whether it receives a data response message (also known as the seventh message) sent by the ADSP subsystem within a preset time period t1 (also known as the third preset time period); if not, proceed to step S203; if yes, end the data acquisition process.

[0150] In this embodiment, the response message used to respond to the data request message is simply referred to as the data response message. Optionally, the data response message may carry sensor data.

[0151] The preset duration t1 is a pre-set time threshold used to determine whether the data request message response has timed out. Within the preset duration t1, it can be understood as within the preset duration t1 after sending the data request message, which will not be elaborated further. Optionally, the AP can set a timer of duration t1 when sending the data request message, and determine whether it receives a data response message from the ADSP subsystem before the timer expires. If a data response message is received before the timer expires, it indicates that the sensor QMI channel communication is normal, and the AP uses the sensor data carried in the data response message to run the service, ending the current sensor data acquisition process. If no data response message is received before the timer expires, it indicates that the data response message has timed out, or that the ADSP subsystem's response to the data request message has timed out, and the sensor QMI channel may be experiencing communication abnormalities. In this case, step S203 is executed to further determine whether the sensor QMI channel is experiencing communication abnormalities.

[0152] S203. The AP side determines whether the number of times the data request message is sent is equal to the preset number threshold N1 (also known as the second number threshold); if yes, then proceed to step S204; if no, then return to step S201.

[0153] The preset threshold N1 is a pre-set maximum number of times a data request message can be sent. N1 can be set according to actual needs, for example, 10 times.

[0154] If the number of times the current data request message has been sent equals the preset threshold N1, meaning the maximum number of transmissions has been reached, and no data response message has been received within the preset time t1, i.e., the ADSP subsystem has timed out after sending N1 data request messages, this situation is also called sensor data request timeout. Sensor data request timeout indicates a communication abnormality in the sensor QMI channel. Therefore, steps S204 and subsequent steps are executed to check whether the communication abnormality is due to a service-level QMI communication function malfunction or a system-level QMI communication function malfunction.

[0155] If the number of times the current data request message is sent is less than the preset threshold N1, that is, the number of times the data request message is sent has not yet reached the corresponding upper limit, then return to step S201 to continue sending data request messages to the ADSP subsystem and continue to determine whether the sensor QMI channel communication is normal.

[0156] In this implementation, a QMI channel communication anomaly is only considered to have occurred if multiple data request messages are sent to the ADSP subsystem and no response is received from the ADSP subsystem after all such messages have been sent. This prevents individual message sending anomalies from being mistaken for QMI channel anomalies, thus improving the accuracy of QMI communication status assessment.

[0157] S204. The AP side sends a detection broadcast message (also known as the first message) to the ADSP subsystem through the fault detection QMI channel (also known as the second QMI channel).

[0158] The detection broadcast message is used to indicate the system-level QMI communication function of the detection subsystem.

[0159] As described above, when communicating via the fault detection QMI channel, the AP acts as the server and the ADSP subsystem acts as the client. The server can have multiple clients, therefore the messages sent are generally broadcast messages.

[0160] Step S204 is followed by step S205.

[0161] S205. The AP side determines whether it receives the detection completion request message (also known as the third message) sent by the ADSP subsystem within the preset time t2 (also known as the first preset time). If not, proceed to step S206; if yes, proceed to step S208.

[0162] The preset duration t1 is a pre-set time threshold used to determine whether the response to the detection broadcast message has timed out. Within the preset duration t2, which can be understood as the preset duration t2 after sending the detection broadcast message, will not be elaborated further.

[0163] When the system-level QMI communication function of the ADSP subsystem is normal, after receiving the detection broadcast message, the ADSP subsystem can check its own system-level QMI communication function. If the system-level QMI communication function is confirmed to be normal, it sends a detection completion request message to the AP side through the fault detection QMI channel. Alternatively, in some embodiments, the ADSP subsystem may not perform QMI communication function testing after receiving the detection broadcast message and may directly send a detection completion request message to the AP side. It can be understood that the detection completion message can be interpreted as a response from the ADSP subsystem to the detection broadcast message. Regardless of the implementation method, as long as the AP side receives the detection completion request message sent by the ADSP subsystem within the preset time t2 after sending the detection broadcast message, it indicates that the ADSP subsystem can normally respond to the detection broadcast message sent by the AP side, and thus indicates that the fault detection QMI channel can communicate normally. The fault detection QMI channel is the channel between the AP side and the root process of the ADSP subsystem. The fact that the fault detection QMI channel can communicate normally indicates that the system-level QMI communication function of the ADSP subsystem is normal. The communication abnormality of the sensor QMI channel is likely caused by the abnormality of the service-level QMI communication function. Therefore, step S208 is executed to restart the sensor process in the ADSP subsystem to restore the communication of the sensor QMI channel.

[0164] In the event of a system-level QMI communication malfunction in the ADSP subsystem, the ADSP subsystem may be unable to receive the detection broadcast message, or may receive the detection broadcast message but fail to send the detection completion request message on time. Therefore, if the AP does not receive the detection completion request message from the ADSP subsystem within a preset time t2 after sending the detection broadcast message, it indicates that the detection completion request message has timed out, or that the ADSP subsystem's response to the detection broadcast message has timed out. This suggests a possible communication malfunction in the fault detection QMI channel, and the sensor QMI channel's communication malfunction may be caused by a system-level QMI communication malfunction. Therefore, step S206 is executed to further determine whether the system-level QMI communication function is malfunctioning.

[0165] S206. The AP side determines whether the number of times the broadcast message has been sent is equal to the preset number threshold N2 (also known as the first number threshold); if yes, then proceed to step S207; if no, then return to step S204.

[0166] The preset threshold N2 is the maximum number of times a detection broadcast message can be sent. N2 can be set according to actual needs, for example, 3 times.

[0167] If the current number of broadcast messages sent equals the preset threshold N2, meaning the maximum number of transmissions has been reached, and no detection completion request message has been received (i.e., the ADSP subsystem has timed out after sending N2 broadcast messages), this situation is also called detection timeout. A detection timeout indicates an abnormality in the fault detection QMI channel communication, meaning the ADSP subsystem's system-level QMI communication function is malfunctioning. In this case, proceed to step S207 to restart the ADSP subsystem and restore its QMI communication function.

[0168] If the current number of detection broadcast messages sent is less than the preset number threshold N2, that is, the number of detection broadcast messages sent has not yet reached the corresponding upper limit, then return to step S204 to continue sending detection broadcast messages to the ADSP subsystem and continue to determine whether the system-level QMI communication function is abnormal.

[0169] In this implementation, multiple detection broadcast messages are sent to the ADSP subsystem. Only when no response is received from the ADSP subsystem after multiple detection broadcast messages are sent is the fault detection QMI channel communication considered abnormal, and the system-level QMI communication function of the ADSP subsystem considered abnormal. This prevents individual message sending anomalies from being identified as system-level QMI communication function abnormalities, improving the accuracy of fault diagnosis, thereby improving the accuracy of restart method selection and enhancing user experience.

[0170] S207, the AP side sends a subsystem restart command (also known as the first command) to the ADSP subsystem by restarting the Glink channel (also known as the first Glink channel) through the subsystem restart.

[0171] In the method provided in this application embodiment, the ADSP subsystem is restarted when the system-level QMI communication function of the ADSP subsystem malfunctions. Since the system-level QMI communication function malfunctions, the subsystem restart command can no longer be transmitted via the QMI channel. Therefore, the Glink channel ensures that the subsystem restart command is accurately and promptly transmitted to the ADSP subsystem, thereby enabling timely restart of the ADSP subsystem and timely restoration of QMI communication.

[0172] The process restart request is used to request a restart of the ADSP subsystem. Upon receiving the subsystem restart request, the ADSP subsystem restarts.

[0173] It is understandable that the ADSP subsystem will execute the above after restarting. Figure 5The process shown involves re-registering the port information corresponding to the detection response module with the AP side. Additionally, after the ADSP subsystem restarts, it can send a subsystem restart signal (also known as the first signal) to the AP side. Upon receiving the subsystem restart signal, the AP side can re-execute step S201, sending a data request message to the ADSP subsystem via the sensor QMI channel.

[0174] S208, the AP side sends a process restart request message (also known as the second message) to the ADSP subsystem through the process restart QMI channel (also known as the third QMI channel).

[0175] If the AP receives a detection completion request message from the ADSP subsystem within a preset time period t2, the AP further sends a process restart request message to the ADSP. The process restart request message requests the restart of the sensor process running in the ADSP subsystem. Upon receiving the process restart request message, the ADSP subsystem attempts to restart the sensor process. If the sensor process restarts successfully, the ADSP subsystem returns a response message to the AP via the process restart QMI channel. In this embodiment, the message used to respond to the process request message is called the process restart response message (also known as the fifth message). If the sensor process restart fails, the ADSP subsystem does not send a restart response message.

[0176] It should be noted that in the CS communication structure, request messages and response messages appear in pairs. Therefore, after receiving the detection completion request message, the AP side also returns a response message to the ADSP subsystem via the fault detection QMI channel (hereinafter referred to as the detection completion response message, also known as the fourth message). For simplicity, Figure 6 Not shown in the image.

[0177] Step S209 is executed after step S208.

[0178] S209. The AP side determines whether it receives the process restart response message (i.e., the fifth message) sent by the ADSP subsystem within the preset time t3 (also known as the second preset time). If not, proceed to step S207; if yes, return to step S201.

[0179] The preset duration t3 is a pre-set time threshold used to determine whether the process restart response message has timed out. Within the preset duration t3, it can be understood as within the preset duration t3 after the process restart message is sent, which will not be elaborated further.

[0180] If the AP receives a process restart response message from the ADSP subsystem within a preset time t3 after sending the process restart request message, it indicates that the sensor process has been successfully restarted. Therefore, it returns to step S201 and resends the data request message to the ADSP subsystem through the sensor QMI channel.

[0181] If the AP does not receive a process restart response message from the ADSP subsystem within a preset time t3 after sending the process restart request message, it indicates that the sensor process has most likely failed to restart. Therefore, step S207 is executed to restart the ADSP subsystem.

[0182] In this step, setting a preset duration t3 prevents indefinite waiting for a process restart response message, thereby improving the algorithm's operating efficiency.

[0183] In summary, the communication fault handling method provided in this embodiment allows the AP side to send a detection broadcast message to the ADSP subsystem via the fault detection QMI channel between itself and the root process of the ADSP subsystem when the service QMI channel communication is abnormal. Based on the ADSP subsystem's response to the detection broadcast message, it is determined whether the ADSP subsystem is experiencing a service-level or system-level QMI communication failure. If a detection completion request message sent by the ADSP subsystem via the fault detection QMI channel is received normally (within a preset duration t3), it indicates a service-level QMI communication failure. The communication of the service QMI channel is restored by restarting the process of that service in the ADSP subsystem. This prevents impact on other services in the ADSP subsystem and thus on user experience. For example, if the sensor QMI channel communication is abnormal, only the sensor process is restarted, without restarting the ADSP subsystem. This avoids impacting the audio and charging processes in the ADSP subsystem, preventing audio interruptions, silence, inaccurate battery display, charging failure due to the inability to send battery data to the AP side, and preventing electronic devices from shutting down, thus improving the user experience.

[0184] If the detection completion request message sent by the ADSP subsystem through the fault detection QMI channel is not received normally (not received within the preset time t3), it indicates that the system-level QMI communication function is abnormal. The system-level QMI communication function is restored by restarting the ADSP subsystem. This not only restores the communication of the currently faulty QMI channel, but also restores the communication of other QMI channels, preventing other services from failing and further improving the user experience.

[0185] In addition, this method also monitors the process restart status. If the AP side does not receive a process restart response message from the ADSP subsystem within a preset time period t3, it indicates that the process restart has failed. In the event of a process restart failure, the AP side further sends a subsystem restart command to the ADSP subsystem to control the restart of the ADSP subsystem, thereby further ensuring the reliability of the QMI communication function.

[0186] The communication fault handling method provided in this embodiment has been introduced from the perspective of the AP. The following will combine... Figure 2 The software architecture shown, and Figure 4 The channel shown will be used to further illustrate this method.

[0187] Continuing with the example of a sports and health application needing to acquire sensor data but experiencing an anomaly in the sensor's QMI channel communication, this method will be explained. First, the data acquisition process will be described.

[0188] For example, Figure 7-1 and Figure 7-2 This is a flowchart illustrating another communication fault handling method provided in an embodiment of this application, as shown below. Figure 7-1 and Figure 7-2 As shown, the data acquisition process may include S301 to S307:

[0189] S301, the sports and health application in the AP side application layer calls the sensor service in the application framework layer.

[0190] Specifically, when a sports and health application needs sensor data, it can call the sensor service in the application framework layer via an API interface. Optionally, when calling the sensor service, the type information of the sensor data can be included.

[0191] S302, the sensor service on the AP side responds to the call from the sports and health application by calling the sensor hardware abstraction layer of the hardware abstraction layer.

[0192] Similarly, when calling the sensor hardware abstraction layer, the type information of the sensor data can also be carried.

[0193] In response to sensor service calls, the sensor hardware abstraction layer on the S303 and AP sides sends data request messages to the sensor processing middleware in the ADSP subsystem based on the sensor QMI channel.

[0194] When sensor QMI channel communication is normal, the sensor processing middleware responds to data request messages by invoking the corresponding sensor driver in the driver layer. The sensor driver then drives the corresponding sensor in the hardware layer to collect raw data. The sensor sends the collected raw data to the sensor driver, which in turn sends it to the sensor processing middleware. The sensor processing middleware processes the raw data to obtain the sensor data. Finally, the sensor processing middleware returns a data response message to the sensor hardware abstraction layer on the AP side via the QMI channel, carrying the sensor data in the response message.

[0195] In the event of a communication failure in the sensor QMI channel, the sensor processing middleware may be unable to receive the data request message, or it may be able to receive the data request message but be unable to return the data response message to the sensor hardware abstraction layer.

[0196] S304. The sensor hardware abstraction layer on the AP side confirms whether a data response message has been received within the preset time period t1; if so, proceed to step S305 (see...). Figure 7-1 If not, proceed to step S307 (see...). Figure 7-2 ).

[0197] The S305 and AP side sensor hardware abstraction layer returns sensor data to the sensor service.

[0198] Step S305 is followed by step S306.

[0199] S306, the sensor service on the AP side returns sensor data to the sports and health application.

[0200] S307. The sensor hardware abstraction layer on the AP side determines whether the number of times the data request message is sent is equal to the preset number threshold N1. If yes, the subsequent fault handling process is executed, specifically step S401 in the subsequent embodiment. If no, the process returns to step S303.

[0201] The processes of steps S303 to S307 above are the same as those of... Figure 6 Steps S201 to S203 correspond to each other and will not be repeated here.

[0202] Next, the fault handling process will be further explained. After executing the above steps S301 to S307, and determining that the sensor data request has timed out (i.e. Figure 7-2 If the result of step S307 is negative, the fault handling procedure is executed. Based on the above... Figure 6The logic shown allows for three scenarios in the fault handling process: Scenario 1: System-level QMI communication is normal, and the process restarts successfully (S205 and S209 both result in "Yes"); Scenario 2: System-level QMI communication is normal, but the process restart fails (S205 and S209 both result in "No"); Scenario 3: System-level QMI communication is abnormal (S205 and S209 both result in "No"). These three scenarios will be explained below.

[0203] Scenario 1: The system-level QMI communication function is normal, and the process restarts successfully.

[0204] For example, Figure 8 This is a flowchart illustrating another communication fault handling method provided in an embodiment of this application, as shown below. Figure 8 As shown, in the following situation, the fault handling process may include:

[0205] S401, the sensor hardware abstraction layer on the AP side calls the fault detection module.

[0206] In response to the call from the sensor hardware abstraction layer, the fault detection module on the S402 and AP sides sends a detection broadcast message to the detection response module in the kernel layer of the ADSP subsystem based on the fault detection QMI channel.

[0207] As in the above embodiment, the detection response module is located in the kernel layer and runs in the root process.

[0208] Optionally, the detection broadcast message can be represented as health_check_ind_msg. Here, health_check represents a health check, and ind_msg represents a broadcast notification message.

[0209] In response to the detection broadcast message, the detection response module in the S403 and ADSP subsystem sends a detection completion request message to the fault detection module on the AP side within a preset time t2, based on the fault detection QMI channel.

[0210] Optionally, the check completion request message can be represented as health_check_complete_req_msg. Here, "complete" indicates completion, and "req_msg" represents the request message.

[0211] S404, the fault detection module on the AP side responds to the detection completion request message and returns a detection completion response message (i.e., a detection completion response message) to the detection response module in the ADSP subsystem based on the fault detection QMI channel.

[0212] Optionally, the check completion request message can be represented as health_check_complete_resp_msg. Here, resp_msg represents the response message.

[0213] S405, the fault detection module on the AP side responds to the detection completion request message and returns detection result 1 to the sensor hardware abstraction layer.

[0214] Test result 1 indicates that the system-level QMI communication function of the ADSP subsystem is normal.

[0215] Optionally, the fault detection module can return the detection results of the system-level QMI communication function to the sensor hardware abstraction layer through preset fields. For example, a value of 1 for preset field a indicates that the system-level QMI communication function is normal, and a value of 0 for preset field a indicates that the system-level QMI communication function is abnormal.

[0216] After receiving the detection result 1, the sensor hardware abstraction layer on the S406 and AP sides calls the process restart control module.

[0217] In response to the call from the sensor hardware abstraction layer, the process restart control module on the S407 and AP sides sends a process restart request message to the process restart module in the kernel layer of the ADSP subsystem based on the process restart QMI channel.

[0218] Optionally, the process restart request message can carry the identifier of the sensor process. Specifically, after creating each process, the ADSP subsystem can send process-related information, including the process identifier, to the corresponding module on the AP side, where the AP side stores the information for each process. In this way, when the process restart control module sends a process restart request to the ADSP subsystem, it can include the process identifier, allowing the ADSP subsystem to know which process needs to be restarted.

[0219] Optionally, a process restart request message can be represented as SERVEG_NOTIF_RESTART_PD_REQ. Here, RESTART_PD indicates restarting the process, and REQ indicates a request message.

[0220] The process restart module in the S408 and ADSP subsystem responds to the process restart request message and restarts the sensor process.

[0221] As can be understood, the process restart module runs in the root process and can control other processes in the ADSP subsystem. Upon receiving a process restart request message, it can control the sensor process to restart based on the sensor process identifier in the process restart request message.

[0222] After the sensor process restarts successfully, the process restart module in the S409 and ADSP subsystem returns a process restart response message to the process restart control module on the AP side via the fault detection QMI channel within a preset time t2.

[0223] Optionally, the process restart response message can be represented as SERVEG_NOTIF_RESTART_PD_RESP. Here, RESP stands for response message.

[0224] After receiving the process restart response message, the process restart control module on the S410 and AP sides returns the process restart result 1 to the sensor hardware abstraction layer.

[0225] A process restart result of 1 indicates that the process restart was successful. Optionally, the process restart result 1 can include the identifier of the sensor process.

[0226] After receiving the process restart result 1, the sensor hardware abstraction layer can re-execute steps S303 and S304 in the data acquisition process.

[0227] Scenario 2: The system-level QMI communication function is normal, but the process restart fails.

[0228] For example, Figure 9 This is a flowchart illustrating another communication fault handling method provided in an embodiment of this application, as shown below. Figure 9 As shown, in scenario two, the fault handling process may include:

[0229] S401, the sensor hardware abstraction layer on the AP side calls the fault detection module.

[0230] In response to the call from the sensor hardware abstraction layer, the fault detection module on the S402 and AP sides sends a detection broadcast message to the detection response module in the kernel layer of the ADSP subsystem based on the fault detection QMI channel.

[0231] In response to the detection broadcast message, the detection response module in the S403 and ADSP subsystem sends a detection completion request message to the fault detection module on the AP side within a preset time t2, based on the fault detection QMI channel.

[0232] In response to the detection completion request message, the fault detection module on the S404 and AP sides returns a detection completion response message to the detection response module in the ADSP subsystem based on the fault detection QMI channel.

[0233] In response to the detection completion request message, the fault detection module on the S405 and AP sides returns detection result 1 to the sensor hardware abstraction layer. Detection result 1 indicates that the system-level QMI communication function of the ADSP subsystem is normal.

[0234] After receiving the detection result 1, the sensor hardware abstraction layer on the S406 and AP sides calls the process restart control module.

[0235] In response to the call from the sensor hardware abstraction layer, the process restart control module on the S407 and AP sides sends a process restart request message to the process restart module in the kernel layer of the ADSP subsystem based on the process restart QMI channel.

[0236] If the process restart control module on the S501 and AP sides does not receive a process restart response message within a preset time t3, it sends process restart result 2 to the sensor hardware abstraction layer. Process restart result 2 indicates that the process restart has failed.

[0237] Optionally, the sensor process identifier can be included in the process restart result 2.

[0238] After receiving process restart result 2, the sensor hardware abstraction layer on the S502 and AP sides calls the subsystem restart control module.

[0239] In response to the call from the sensor hardware abstraction layer, the S503 and AP side subsystem restart control modules send subsystem restart commands to the subsystem restart module in the kernel layer of the ADSP subsystem based on the subsystem restart Glink channel.

[0240] Optionally, the subsystem restart command can be represented as SLEEPMON_SEND_SSR_COMMAND. Here, SSR indicates subsystem restart, and COMMAND represents the command.

[0241] The S504 subsystem restart module in the ADSP subsystem responds to the subsystem restart command and restarts the ADSP subsystem.

[0242] The subsystem restart module runs in the root process of the kernel layer of the ADSP subsystem. After receiving the subsystem restart command, it calls its own interface to reset the entire ADSP subsystem.

[0243] After a successful subsystem restart, the subsystem restart module in the S505 and ADSP subsystems returns a subsystem restart signal (i.e., the first signal) to the subsystem restart control module on the AP side via the subsystem restart Glink channel.

[0244] After receiving the subsystem restart signal, the S506 and AP side subsystem restart control modules return the subsystem restart signal to the sensor hardware abstraction layer.

[0245] As one possible implementation, if the subsystem control module on the AP side does not receive a subsystem restart signal from the ADSP subsystem within a preset time t4 after sending the subsystem restart command, it returns a subsystem restart failure message to the sensor hardware abstraction layer. Upon receiving the subsystem restart failure message, the sensor hardware abstraction layer can request the relevant modules on the AP side to restart the entire electronic device to restore the functionality of the ADSP subsystem.

[0246] Scenario 3: System-level QMI communication function is abnormal.

[0247] For example, Figure 10 This is a flowchart illustrating another communication fault handling method provided in an embodiment of this application, as shown below. Figure 10 As shown, in scenario three, the fault handling process may include:

[0248] S401, the sensor hardware abstraction layer on the AP side calls the fault detection module.

[0249] In response to the call from the sensor hardware abstraction layer, the fault detection module on the S402 and AP sides sends a detection broadcast message to the detection response module in the kernel layer of the ADSP subsystem based on the fault detection QMI channel.

[0250] S601. If the fault detection module on the AP side does not receive a detection completion request message within a preset time t2, it determines whether the number of times the detection broadcast message is sent is equal to the preset number threshold N2. If yes, then proceed to step S602; otherwise, return to step S402.

[0251] The fault detection module on the S602 and AP sides returns detection result 2 to the sensor hardware abstraction layer. Detection result 2 indicates that the system-level QMI communication function of the ADSP subsystem is abnormal.

[0252] After receiving detection result 2, the sensor hardware abstraction layer on the S603 and AP sides calls the subsystem to restart the control module.

[0253] The S604 and AP-side subsystem restart control modules respond to the hardware abstraction layer's call by sending a subsystem restart command to the subsystem restart module in the ADSP subsystem's kernel layer based on the subsystem restart Glink channel.

[0254] The S605 ADSP subsystem's subsystem restart module responds to the subsystem restart command and restarts the ADSP subsystem.

[0255] After a successful subsystem restart, the subsystem restart module in the S606 and ADSP subsystems returns a subsystem restart signal to the subsystem restart control module on the AP side via the subsystem restart Glink channel.

[0256] After receiving the subsystem restart signal, the S607 and AP side subsystem restart control modules return the subsystem restart signal to the sensor hardware abstraction layer.

[0257] The above steps S603 to S607 and Figure 9 Steps S502 to S506 in the illustrated embodiment are similar and will not be described again.

[0258] The foregoing has detailed examples of communication fault handling methods provided in the embodiments of this application. It is understood that, in order to achieve the above functions, the electronic device includes hardware and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in conjunction with the embodiments, but such implementation should not be considered beyond the scope of this application.

[0259] This application embodiment can divide the electronic device into functional modules according to the above method example. For example, each function can be divided into a separate functional module, such as a detection unit, a processing unit, a display unit, etc., or two or more functions can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0260] It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0261] The electronic device provided in this embodiment is used to execute the above-described communication fault handling method, and therefore can achieve the same effect as the above-described implementation method.

[0262] When using integrated units, the electronic device may further include a processing module, a storage module, and a communication module. The processing module is used to control and manage the operation of the electronic device. The storage module supports the execution of stored program code and data. The communication module supports communication between the electronic device and other devices.

[0263] The processing module can be a processor or a controller. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a digital signal processor (DSP), and a microprocessor, etc. The storage module can be a memory. The communication module can specifically be a radio frequency circuit, a Bluetooth chip, a Wi-Fi chip, or other devices that interact with other electronic devices.

[0264] In one embodiment, when the processing module is a processor and the storage module is a memory, the electronic device involved in this embodiment can be a device having... Figure 1 The device with the structure shown.

[0265] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the communication fault handling method of any of the above embodiments.

[0266] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the communication fault handling method described in the above embodiments.

[0267] In addition, embodiments of this application also provide an apparatus, which may specifically be a chip, component, or module. The apparatus may include a connected processor and a memory. The memory is used to store computer execution instructions. When the apparatus is running, the processor can execute the computer execution instructions stored in the memory to cause the chip to execute the communication fault handling methods in the above-described method embodiments.

[0268] In this embodiment, the electronic device, computer-readable storage medium, computer program product or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0269] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0270] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0271] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0272] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0273] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0274] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A communication fault handling method, wherein the method is executed by an electronic device, characterized in that, The electronic device includes an application processor (AP) and an application digital signal processor (ADSP). At least one first QMI channel for transmitting services exists between the AP and the ADSP. A second QMI channel and a third QMI channel also exist between the AP and the kernel layer of the ADSP. The method includes: In the event of a communication failure on the fourth QMI channel, the AP sends a first message to the ADSP through the second QMI channel; the fourth QMI channel is any one of at least one of the first QMI channels, and the fourth QMI channel is used to transmit data for the first service; If the ADSP's response to the first message does not time out, the AP sends a second message to the ADSP through the third QMI channel; the second message is used to request the restart of the process corresponding to the first service in the ADSP. If the ADSP times out in response to the first message, the AP sends a first instruction to the ADSP, which instructs the restart of the subsystem running in the ADSP.

2. The method according to claim 1, characterized in that, Before the AP sends the second message to the ADSP through the third QMI channel if the ADSP's response to the first message does not time out, the method further includes: If the AP receives a third message sent by the ADSP through the second QMI channel within a first preset time period after sending the first message, it is determined that the ADSP's response to the first message has not timed out; the third message is used to respond to the first message. If the AP does not receive the third message sent by the ADSP through the second QMI channel within the first preset time period after sending the first message, the AP determines whether the number of times the first message is sent is equal to the first number threshold. If the number of times the first message is sent is equal to the first number threshold, then the ADSP's response to the first message is determined to have timed out; If the number of times the first message is sent is less than the first number threshold, then return to the execution step: the AP sends the first message to the ADSP through the second QMI channel.

3. The method according to claim 2, characterized in that, During communication based on the second QMI channel, the AP acts as the server and the ADSP acts as the client.

4. The method according to claim 3, characterized in that, The first message is a broadcast notification message, while the second and third messages are both request messages.

5. The method according to claim 4, characterized in that, The method further includes: If the AP receives the third message sent by the ADSP through the second QMI channel within the first preset time period after sending the first message, the AP sends a fourth message to the ADSP, the fourth message being a response message to the third message.

6. The method according to claim 3, characterized in that, Before the AP sends the first message to the ADSP through the second QMI channel, the method further includes: In response to the power-on of the ADSP, the ADSP sends a registration request message to the AP, the registration request message being used to request registration port information.

7. The method according to claim 1, characterized in that, After the AP sends the second message to the ADSP through the third QMI channel, the method further includes: If the AP does not receive the fifth message sent by the ADSP through the third QMI channel within a second preset time period after sending the second message, the AP sends the first instruction to the ADSP; the fifth message is a response message to the second message.

8. The method according to claim 1, characterized in that, A first Glink channel also exists between the AP and the kernel layer of the ADSP. The AP sends a first instruction to the ADSP. The method includes: The AP sends the first instruction to the ADSP through the first Glink channel; After the AP sends the first instruction to the ADSP, the method further includes: After the subsystem running in the ADSP successfully restarts, the ADSP sends a first signal to the AP through the first Glink channel.

9. The method according to any one of claims 1 to 8, characterized in that, In the event of a communication failure on the fourth QMI channel, before the AP sends the first message to the ADSP via the second QMI channel, the method further includes: The AP sends a sixth message through the fourth QMI channel; the sixth message is used to request data for the first service. If the AP does not receive the seventh message sent by the ADSP through the fourth QMI channel within a third preset time period after sending the sixth message, it is determined that the fourth QMI channel communication is normal; the seventh message is a response message to the sixth message. If the AP does not receive the seventh message sent by the ADSP through the fourth QMI channel within the third preset time period after sending the sixth message, then it is determined whether the number of times the sixth message was sent is equal to the second threshold. If the number of times the sixth message is sent is equal to the second threshold number, then the fourth QMI channel communication is determined to be abnormal. If the number of times the sixth message is sent is less than the second threshold, then return to the execution step: the AP sends the sixth message to the AP through the fourth QMI channel.

10. The method according to any one of claims 1 to 8, characterized in that, The first QMI channel is used to transmit sensor service data, audio service data, or charging service data.

11. An electronic device, characterized in that, The electronic device includes: multiple processors and a memory; the multiple processors include an application processor (AP) and an application digital signal processor (ADSP); The memory is coupled to the plurality of processors and is used to store computer program code, the computer program code including computer instructions, which the plurality of processors invoke to cause the electronic device to perform the method as described in any one of claims 1 to 10.

12. A chip system, characterized in that, The chip system is applied to an electronic device, the chip system including multiple processors, the multiple processors including an application processor (AP) and an application digital signal processor (ADSP), the multiple processors being used to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1 to 10.

Images