Communication method, electronic device, and storage medium
By recording the time information of service data on the ADSP side, the problem of difficulty in locating the root cause of timeout in AP-ADSP communication is solved, thereby improving the communication reliability and fault resolution efficiency of electronic equipment.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- HONOR DEVICE CO LTD
- Filing Date
- 2024-08-30
- Publication Date
- 2026-05-01
AI Technical Summary
In the prior art, during the communication process between the application processor (AP) and the application digital signal processor (ADSP) of an electronic device, when the AP receives or sends data and the timeout occurs, it is impossible to accurately locate the root cause of the timeout, making it difficult for R&D personnel to effectively solve the timeout fault.
By recording the queuing time, start processing time and end processing time of service data on the ADSP side, timeout information is generated and sent to the AP. The AP can accurately locate the timeout cause based on these time differences, including whether the ADSP has exceeded the limit for receiving data or has timed out processing a single piece of data.
It enables precise location of AP data transmission and reception timeouts, helping R&D personnel to address timeout faults in a targeted manner, prevent ADSP queue blocking, and improve communication reliability.
Smart Images

Figure CN120750735B_ABST
Abstract
Description
Communication methods, electronic devices and storage media Technical Field
[0001] This application relates to the field of electronic technology, specifically to a communication method, an electronic device, and a storage medium. Background Technology
[0002] Currently, in the architecture of electronic devices, different functions can be achieved through the cooperation between the application processor (AP) side and the application digital signal processor (ADSP) side. For example, the AP side can control the ADSP side to achieve functions such as audio processing, sensor data acquisition, charging management, and battery management.
[0003] In implementing the above functions, the AP side and the ADSP side communicate through the inter-core communication link (GLink) of the Power Management Integrated Circuit (PMIC). For example, the AP side sends data to the ADSP side through the PMIC GLink, and correspondingly, the AP side also receives response data sent by the ADSP side through the PMIC GLink.
[0004] However, during the aforementioned communication process, there are issues with timeouts in data reception or transmission on the AP side. When this occurs, the cause of the timeout is usually determined by analyzing the kernel logs. However, related technologies can only determine that the AP side has timed out data transmission, but cannot accurately pinpoint the root cause of the AP side's data transmission and reception timeouts, which is not conducive to developers resolving timeout faults. Summary of the Invention
[0005] This application provides a communication method, electronic device, and storage medium that can accurately locate the root cause of AP data transmission and reception timeouts, which helps researchers better solve timeout faults.
[0006] Firstly, this application provides a communication method applied to an electronic device, which includes an ADSP. The ADSP receives service data sent by an application processor (AP), detects that the receive queue in the ADSP is not full, stores the service data in the receive queue, and adds an enqueue time to the service data; processes the service data and records the start processing time corresponding to the service data; when the processing of the service data is completed, records the end processing time corresponding to the service data; if the processing of the service data times out, the ADSP sends timeout information to the AP, the timeout information including the enqueue time, start processing time, and end processing time of the service data, and the AP can determine the cause of the timeout based on the timeout information.
[0007] Business data can include business instructions / commands, business requests, business content data (such as audio data), metadata, configuration parameters, system status information, network data, etc.
[0008] Optionally, the AP and ADSP communicate via the GLink inter-core communication link of the power management integrated circuit (PMIC).
[0009] Optionally, ADSP processing service data timeouts may include processing timeouts for individual service data, i.e., processing timeouts for service data corresponding to a single service, or timeouts caused by excessive service data received by the receive queue in the ADSP.
[0010] In this implementation, the ADSP adds an enqueue time to the business data when it enqueues it, records the start processing time when it begins processing the data, and records the end processing time when the data processing is completed. If the ADSP times out processing the business data, it sends timeout information, including the enqueue time, start processing time, and end processing time, to the AP. The AP can calculate the time difference based on the enqueue time and end processing time in the timeout information, and also calculate the time difference based on the end processing time and start processing time. By using these different time differences, the root cause of the AP's data transmission and reception timeout can be accurately located.
[0011] In conjunction with the first aspect, in some implementations of the first aspect, timeout information is used by the AP to determine a first time difference and / or a second time difference, and to determine the timeout reason based on the first time difference and / or the second time difference; the first time difference is determined based on the end processing time and the enqueue time, and the second time difference is determined based on the end processing time and the start processing time;
[0012] If the timeout reason is determined based on the first time difference, the timeout reason is that the number of service data received by the ADSP exceeds the preset number of received data; if the timeout reason is determined based on the second time difference, the timeout reason is that the ADSP times out processing a single service data; if the timeout reason is determined based on both the first and second time differences, the timeout reason is that the number of service data received by the ADSP exceeds the preset number of received data, and the ADSP times out processing a single service data.
[0013] This implementation allows the AP to accurately pinpoint the root cause of timeouts, enabling developers to address timeout issues more effectively. For example, if the identified timeout cause includes the ADSP receiving more service data than the preset limit, the AP can be controlled to stop sending service data frequently, effectively preventing excessive service data from blocking the ADSP, reducing its workload, and resolving the AP's data transmission and reception timeout problem. If the identified timeout cause includes a single service data timeout by the ADSP, then patiently wait for the ADSP's response.
[0014] In conjunction with the first aspect, in some implementations of the first aspect, the service data sent by the AP includes identification information. Before detecting that the receive queue in the ADSP is not full, the service data is stored in the receive queue and an enqueue time is added to the service data, the communication method further includes: determining, based on the identification information, whether there is identical service data corresponding to the service data in the receive queue; if there is no identical service data in the receive queue, detecting whether the receive queue in the ADSP is not full.
[0015] Identification information may include any one or any combination of serial numbers, randomly generated unique values, hash values, etc.
[0016] In this implementation, it is possible to determine whether the service data currently sent by the AP is duplicate service data based on the identification information. Based on the determination result, the service data currently sent is processed differently, avoiding the storage of a large amount of duplicate service data in the ADSP's receive queue, preventing the ADSP's receive queue from overflowing, and reducing the risk of the ADSP being blocked due to repeatedly receiving the same service data.
[0017] In conjunction with the first aspect, in some implementations of the first aspect, after determining whether there is identical business data corresponding to the business data in the receiving queue based on the identification information, the communication method further includes: if there is identical business data corresponding to the business data in the receiving queue, then discard the business data.
[0018] This implementation avoids storing a large amount of duplicate service data in the ADSP's receive queue, prevents the ADSP's receive queue from overflowing, and reduces the risk of the ADSP being blocked due to repeatedly receiving the same service data.
[0019] In conjunction with the first aspect, in some implementations of the first aspect, if there is no identical service data corresponding to the service data in the receiving queue, and the receiving queue in the ADSP is full, the service data is stored in a preset discard queue, and a discard time is added to the service data.
[0020] In this implementation, adding a discard time to the discarded business data can provide accurate information about the discarded business data, making it easier to determine the waiting time of the business data in the discard queue.
[0021] In conjunction with the first aspect, in some implementations of the first aspect, business data is processed and the start processing time corresponding to the business data is recorded, including: retrieving business data from the receiving queue; starting a preset timeout timer; obtaining the start processing time corresponding to the business data; and calling the business processing function corresponding to the business data to perform business processing.
[0022] In this implementation, a timeout timer is added to monitor whether the service processing has timed out. This allows for different processing procedures to be adopted based on whether a timeout is detected or not, thereby improving the reliability of communication between the AP and ADSP.
[0023] In conjunction with the first aspect, in some implementations of the first aspect, the communication method further includes: if the timeout timer detects that the service processing has timed out, triggering the ADSP to call the interrupt callback function; and restarting the ADSP using the interrupt callback function.
[0024] In this implementation, because we enable a timeout timer, when the timeout timer monitors for a timeout, it triggers an interrupt callback function, which restarts the ADSP and restores its normal operation. This effectively solves the problem of not being able to restore ADSP operation in a timely manner in related technologies.
[0025] In conjunction with the first aspect, in some implementations of the first aspect, the communication method further includes: generating a dump file; sending the dump file to the AP, wherein the dump file is used by the AP to determine the timeout cause, and the timeout cause is a failure of the ADSP.
[0026] In this implementation, an ADSP restart will trigger the generation of a dump file, which will be automatically sent to the AP to facilitate analysis of the root cause of AP data transmission and reception timeouts.
[0027] In conjunction with the first aspect, in some implementations of the first aspect, the communication method further includes: if the timeout timer detects that the business processing has not timed out, recording the end processing time corresponding to the business data.
[0028] In this implementation, the end processing time corresponding to the business data is recorded, which provides a guarantee for subsequent AP analysis of the timeout reasons.
[0029] Secondly, this application provides a communication method applied to an electronic device, the electronic device including an application processor (AP), the communication method including: the AP adding identification information to service data; encapsulating the service data with added identification information; sending the encapsulated service data to an application digital signal processor (ADSP); receiving timeout information sent by the ADSP, the timeout information including the enqueue time, start processing time, and end processing time corresponding to the service data; and determining the timeout reason based on the timeout information.
[0030] In this implementation, the AP adds identification information to the service data before sending it to the ADSP. This helps the ADSP filter duplicate service data based on the identification information, improves the utilization of the receiving queue, and reduces the risk of the ADSP being blocked due to repeatedly receiving the same service data.
[0031] In conjunction with the second aspect, in certain implementations of the second aspect, determining the timeout cause based on timeout information includes: determining a first time difference and / or a second time difference based on the timeout information, and determining the timeout cause based on the first time difference and / or the second time difference; the first time difference is determined based on the end processing time and the enqueue time, and the second time difference is determined based on the end processing time and the start processing time; if the timeout cause is determined based on the first time difference, the timeout cause is that the number of service data received by the ADSP exceeds the preset number of received data; if the timeout cause is determined based on the second time difference, the timeout cause is that the ADSP times out processing a single service data; if the timeout cause is determined based on both the first and second time differences, the timeout cause is that the number of service data received by the ADSP exceeds the preset number of received data, and the ADSP times out processing a single service data.
[0032] This implementation method enables the AP to accurately locate the root cause of the timeout, which helps R&D personnel to solve timeout faults in a targeted manner.
[0033] In conjunction with the second aspect, in some implementations of the second aspect, the communication method further includes: obtaining the kernel log corresponding to the AP; if it is detected that the AP has not received any response data sent by the ADSP within a preset time, the timeout reason is determined to include channel blockage between the AP and the ADSP.
[0034] Optionally, the AP and ADSP communicate via the GLink inter-core communication link of the power management integrated circuit (PMIC).
[0035] In this implementation, analyzing kernel logs helps the application determine the true cause of timeouts, which in turn helps developers address timeout faults in a targeted manner.
[0036] Thirdly, this application provides an apparatus included in an electronic device. This apparatus has the function of implementing the electronic device behavior described in the first aspect and its possible implementations, and also has the function of implementing the electronic device behavior described in the second aspect and its possible implementations. The functions 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 functions. For example, a receiving module or unit, a processing module or unit, etc.
[0037] Fourthly, this application provides an electronic device including an application digital signal processor (ADSP) and an application processor (AP), wherein the ADSP executes any one of the technical solutions of the first aspect described above, and the AP executes any one of the technical solutions of the second aspect described above.
[0038] Fifthly, this application provides a chip system including a processor. The processor is configured to read and execute a computer program stored in a memory to perform the methods in the first aspect and any possible implementation thereof, and / or to perform the methods in the second aspect and any possible implementation thereof.
[0039] Optionally, the chip system may also include memory, which is connected to the processor via circuitry or wires.
[0040] Alternatively, the chip system may also include a communication interface.
[0041] Sixthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform any method of the technical solution of the first aspect and / or perform any method of the technical solution of the second aspect.
[0042] In a seventh aspect, this application provides a computer program product comprising: computer program code, which, when executed on an electronic device, causes the electronic device to perform any method of the technical solution of the first aspect, and / or perform any method of the technical solution of the second aspect. Attached Figure Description
[0043] Figure 1 is a schematic diagram of communication between an AP and an ADSP provided in an embodiment of this application;
[0044] Figure 2 is a schematic diagram of the structure of an electronic device illustrated in an exemplary embodiment of this application;
[0045] Figure 3 is a software structure block diagram of an electronic device illustrated in an exemplary embodiment of this application;
[0046] Figure 4 is a flowchart illustrating a communication method provided in an embodiment of this application;
[0047] Figure 5 is a flowchart illustrating a method for sending service data according to an embodiment of this application;
[0048] Figure 6 is a schematic diagram of another queuing process provided in an embodiment of this application;
[0049] Figure 7 is a flowchart illustrating a method for processing business data according to an embodiment of this application;
[0050] Figure 8 is a flowchart illustrating a method for restarting an ADSP according to an embodiment of this application;
[0051] Figure 9 is a flowchart illustrating a method for sending a dump file according to an embodiment of this application;
[0052] Figure 10 is a flowchart illustrating an ADSP communication execution method provided in an embodiment of this application;
[0053] Figure 11 is a flowchart illustrating an AP communication method according to an embodiment of this application;
[0054] Figure 12 is a flowchart illustrating another method for performing communication according to an embodiment of this application;
[0055] Figure 13 is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation
[0056] 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.
[0057] 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.
[0058] 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.
[0059] To better understand the embodiments of this application, the terms or concepts that may be involved in the embodiments are explained below.
[0060] 1. Kernel Logs
[0061] Kernel logs typically refer to log information generated by the operating system kernel, used to record information such as events, operations, and state changes generated during the operation of the system, applications, or services.
[0062] Kernel logs are typically stored in chronological order and in a specific format as text. They can contain various types of information, such as error messages, warning messages, debugging messages, and normal operation process information.
[0063] 2. Dump file
[0064] A dump file, also known as a memory dump file, is typically a complete snapshot of the data or system state in memory. A dump file can include the process's memory space, register values, system configuration information, etc. The data in a dump file can be in binary format.
[0065] Typically, dump files are generated when a system or application experiences a serious failure or crash.
[0066] Both kernel logs and dump files can be used to locate and analyze problems in a system or application, and they can complement each other. For example, when a system or application malfunctions, kernel logs can provide relevant information before and after the malfunction, while dump files can provide detailed system states at the time of the malfunction. Combining the two can more comprehensively determine the root cause of the problem.
[0067] 3. Inter-core communication link (GLink) of Power Management Integrated Circuit (PMIC)
[0068] PMIC Glink is a communication mechanism used to connect processors and chips, enabling processors to send commands, request data, and obtain status information to the PMIC via Glink, thereby achieving control and management of the PMIC.
[0069] Glink communication is a multi-layered communication protocol framework primarily used for communication between various intellectual property cores (IPs) within a system-on-chip (SoC).
[0070] In this embodiment, PMIC Glink can be used to realize inter-core communication between the AP and the Communication Processor (CP), ADSP, Computational Digital Signal Processor (CDSP), etc.
[0071] 4. Lock
[0072] A lock is a synchronization mechanism used to control access to shared resources in multi-threaded or multi-process scenarios. Using locks ensures that at any given time, only one thread or process can access a specific resource or code segment, thus avoiding data races and consistency issues.
[0073] Electronic devices may include multiple processors, such as access points (APs), modem processors, ADSPs, CDSPs, baseband processors, and wireless local area network (WLAN) processors.
[0074] The operating system of an electronic device may include a main system running on the AP side (referred to as the AP side in this embodiment) and one or more subsystems running on other processors.
[0075] One or more subsystems may include, but are not limited to, subsystems running on the ADSP side (hereinafter referred to as ADSP subsystems in this application embodiment), subsystems running on the CDSP side (hereinafter referred to as CDSP subsystems in this application embodiment), subsystems running on the modem (hereinafter referred to as modem subsystems in this application embodiment), and subsystems running on the WLAN processor (hereinafter referred to as WLAN subsystems in this application embodiment), etc.
[0076] The ADSP subsystem can be used to implement functions such as audio processing, sensor data acquisition, and charging management (e.g., power statistics, charging control, battery health monitoring, temperature management, overcharge protection, over-discharge protection, short circuit protection, battery equalization, fast charging technology, charging status indication, data recording and analysis, etc.). The CDSP subsystem can be used to implement functions such as image signal processing and encoding / decoding. The WLAN subsystem can be used to implement data processing and transmission during wireless communication. It should be noted that each subsystem can be controlled by the AP side to achieve its respective function.
[0077] This application primarily relates to the interaction between the main system on the AP side and the subsystem on the ADSP side, also known as the interaction between the AP and ADSP. PMIC Glink is an important communication mechanism in the interaction process between the AP and ADSP, used to realize the exchange of different service data between the AP and ADSP. Therefore, normal communication of PMIC Glink plays a decisive role in the normal operation of AP services.
[0078] The process of PMIC Glink-based communication between the AP and ADSP provided in this application is described below with reference to the accompanying drawings.
[0079] Please refer to Figure 1, which is a schematic diagram of communication between an AP and an ADSP provided in an embodiment of this application. When the AP and ADSP communicate based on PMIC Glink, the AP can act as the controller (also known as the master device), and the ADSP can act as the responder (also known as the slave device).
[0080] As shown in Figure 1, the AP may include a driver module and a PMIC Glink module. The driver module can run one or more drivers, such as Universal Charging Interface (UCSI) drivers, QTI Battery drivers, Charger drivers, Ulog drivers, Original Equipment Manufacturer (OEM) drivers, etc.
[0081] UCSI drivers are used to enable communication between the battery and the charger; QTI Battery drivers are used to manage battery status; Charger drivers are used to handle specific needs during the charging process; Ulog drivers are used to acquire and record information such as events, operations, and status changes generated by various hardware and software during operation; OEM drivers are drivers customized for specific devices or products to implement proprietary functions or optimizations.
[0082] ADSP can include a service processing module and a PMIC Glink module. The service processing module can call one or more service processing functions, such as UCSI service processing functions, QTI Battery service processing functions, Charger service processing functions, Ulog service processing functions, OEM service processing functions, etc.
[0083] The UCSI service processing function is used to handle battery and charger communication services; the QTI Battery service processing function is used to handle battery status-related services; the Charger service processing function is used to handle charging services; the Ulog service processing function is used to handle log services; and the OEM service processing function is used to handle specific functions or optimization services.
[0084] For example, a PMIC Glink channel is established between the AP and the ADSP for communication. Specifically, a PMIC Glink driver can run in the PMIC Glink module of both the AP and the ADSP. This PMIC Glink driver acts as the driver for the PMIC Glink channel, enabling data transmission between the AP and the ADSP.
[0085] For example, the Pmic_glink_write driver can run in the AP's PMIC Glink module to write service data from the driver module to the PMIC Glink channel, thereby sending the service data to the ADSP via the PMIC Glink channel. As another example, the Pmic_glink_rx_callback driver can also run in the AP's PMIC Glink module to receive response data sent by the ADSP via the PMIC Glink channel when the ADSP responds to commands from the AP, and then return the response data to the driver module.
[0086] Accordingly, the ADSP's PMIC Glink module can run the Pmic_glink_process_rx_data driver to receive service data transmitted through the PMIC Glink channel and call the corresponding service processing function in the service processing module to process the service data. The ADSP's PMIC Glink module can also run the Pmic_glink_tx driver to send the processing results (i.e., response data) from the service processing module to the AP through the PMIC Glink channel.
[0087] Having understood the process of PMIC Glink-based communication between the AP and ADSP, this application provides several scenarios for PMIC Glink-based communication between the AP and ADSP, as detailed below.
[0088] 1. Sensor data interaction scenarios
[0089] Some AP applications require sensor data during operation. For example, fitness and health applications and chat applications need to obtain acceleration data, gyroscope data, etc., to determine the status of the electronic device and to perform step counting, thereby updating the exercise data; another example is the photo album application, which needs to obtain gravity sensor data and acceleration data to determine whether the electronic device is being rotated, thereby enabling the function of automatic screen rotation.
[0090] When the AP needs to acquire sensor data, it can send a sensor data acquisition request to the ADSP via PMIC Glink. After receiving the sensor data acquisition request, the ADSP reads the sensor data, such as data from the accelerometer and gyroscope. Then, the ADSP returns the sensor data to the AP via PMIC Glink.
[0091] If the AP times out when receiving or sending data (referred to as data transmission and reception in this embodiment), the AP will be unable to send a sensor data acquisition request to the ADSP in a timely manner, or the AP will be unable to receive the sensor data returned by the ADSP in a timely manner, and the AP's application will malfunction. For example, the AP's application may experience problems such as motion data not updating or the screen not rotating, which seriously affects the user experience.
[0092] 2. Audio data interaction scenarios
[0093] When an AP's audio playback application plays audio data, it requires the ADSP to process the audio data. For example, the ADSP needs to decode the audio data. In this case, the AP transmits the audio data to the ADSP via PMIC Glink, and the ADSP decodes the audio data and then sends the decoded data back to the AP via PMIC Glink.
[0094] If the AP times out sending and receiving data, it will be unable to send audio data to the ADSP in a timely manner, or it will be unable to receive the decoded data sent by the ADSP in a timely manner. This will cause the AP's audio playback application to experience abnormal situations such as intermittent audio playback or no sound, which will seriously affect the user experience.
[0095] 3. Battery data interaction scenarios
[0096] During use or charging, electronic devices can have their battery level monitored by the ADSP and transmitted to the AP via PMIC Glink. The AP then updates the battery information on the electronic device's display based on this data and controls the start and stop of charging.
[0097] In scenarios where the device is not charged, if the AP (Access Point) times out sending and receiving data, it cannot send a power data acquisition request to the ADSP (Automatic Power DSP) in a timely manner. At the same time, the AP also cannot receive the power data returned by the ADSP in a timely manner. As a result, the AP cannot update the power information displayed on the screen, causing the power level of the electronic device that the user sees to remain unchanged. The AP cannot remind the user to charge the device in a timely manner, which may lead to the user unknowingly draining the power of the electronic device and making it unable to be turned on and used, seriously affecting the user experience.
[0098] Furthermore, in charging scenarios, if the AP's data transmission and reception times out, and the AP cannot receive the power data sent by the ADSP in time, then the AP cannot control the electronic device to start charging, causing the electronic device to run out of power and shut down, or it cannot control the electronic device to stop charging, resulting in overcharging and damaging battery life.
[0099] Therefore, it is crucial that the PMIC Glink communication between the AP and ADSP is functioning correctly. However, in practical applications, the AP inevitably encounters data transmission / reception timeout issues. In such cases, the AP will report to the kernel log, which records detailed information related to the AP's data transmission / reception timeout. By analyzing the kernel log, the cause of the timeout can be determined.
[0100] However, in related technologies, analyzing kernel logs can only determine that the AP's data transmission and reception timeout is due to the timeout of waiting for the ADSP to respond to the service data sent by the AP, rather than the PMIC Glink blocking causing the AP to be unable to transmit or receive data. However, it cannot accurately locate the root cause of the AP's data transmission and reception timeout, which is not conducive to R&D personnel resolving timeout faults.
[0101] In view of this, embodiments of this application provide a communication method applied to an electronic device, the electronic device including an ADSP. The ADSP receives service data sent by an application processor (AP), detects that the receive queue in the ADSP is not full, stores the service data in the receive queue, and adds an enqueue time to the service data; processes the service data and records the start processing time corresponding to the service data, and records the end processing time corresponding to the service data when the processing of the service data is completed; if the processing of the service data times out, the ADSP sends timeout information to the AP, the timeout information including the enqueue time, start processing time, and end processing time of the service data, and the AP can determine the timeout reason based on the timeout information.
[0102] In this implementation, the ADSP adds an enqueue time to the business data when it enqueues it, records the start processing time when it begins processing the data, and records the end processing time when the data processing is completed. If the ADSP times out processing the business data, it sends timeout information, including the enqueue time, start processing time, and end processing time, to the AP. The AP can calculate the time difference based on the enqueue time and end processing time in the timeout information, and also calculate the time difference based on the end processing time and start processing time. By using these different time differences, the root cause of the AP's data transmission and reception timeout can be accurately located.
[0103] For example, if the time difference between the queuing time and the end processing time of service data is greater than a first preset threshold, it proves that the ADSP has received multiple service data, thus determining that the root cause of the AP's data transmission and reception timeout (i.e., the timeout reason) is that the number of service data received by the ADSP exceeds the preset reception quantity. As another example, if the time difference between the end processing time and the start processing time of service data is greater than a second preset threshold, it proves that the ADSP has timed out processing a single task, thus determining that the root cause of the AP's data transmission and reception timeout (i.e., the timeout reason) is that the ADSP has timed out processing a single service data.
[0104] After accurately locating the root cause of AP data transmission and reception timeouts, it helps R&D personnel to better resolve timeout faults. For example, it is possible to control the AP to prevent it from frequently sending the same service data when it fails to send service data, thereby effectively preventing the ADSP from being blocked due to the AP frequently sending the same service data.
[0105] The structure of the electronic devices involved in the embodiments of this application will be briefly described below with reference to the accompanying drawings.
[0106] In this application embodiment, the electronic device can be a mobile phone, smart screen, tablet computer, wearable in-vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), handheld or laptop device, media player, smart projector, smart TV, desktop computer, in-vehicle infotainment system, etc., including AP and ADSP. This application embodiment does not impose any restrictions on the specific type and form of the electronic device.
[0107] Please refer to Figure 2, which is a schematic diagram of the structure of an electronic device illustrated in an exemplary 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.
[0108] It should be noted that the structure shown in Figure 2 does 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 those shown in Figure 2, or the electronic device 100 may include a combination of some of the components shown in Figure 2, or the electronic device 100 may include sub-components of some of the components shown in Figure 2. The components shown in Figure 2 may be implemented by hardware, software, or a combination of hardware and software.
[0109] Processor 110 may include one or more processing units. For example, processor 110 may include at least one of the following processing units: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, video codec, digital signal processor (DSP), baseband processor, and neural network processing unit (NPU). These different processing units may be independent devices or integrated devices.
[0110] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.
[0111] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.
[0112] Optionally, the processor 110 can run the software code of the communication method provided in the embodiments of this application, receive service data sent by the application processor AP using the ADSP, detect that the receive queue in the ADSP is not full, store the service data in the receive queue, and add an enqueue time to the service data; process the service data and record the start processing time corresponding to the service data, and record the end processing time corresponding to the service data when the service data is processed; if the processing of the service data times out, the ADSP sends timeout information to the AP, the timeout information including the enqueue time, start processing time and end processing time of the service data, and the AP can determine the timeout reason based on the timeout information.
[0113] Electronic device 100 can implement display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU can also be used to perform mathematical and pose calculations, for graphics rendering, etc. Processor 110 may include one or more GPUs, whose executed program instructions can generate or modify display information.
[0114] In some embodiments, the electronic device 100 may include one or N displays 194, where N can be a positive integer greater than 1.
[0115] The display screen 194 in this embodiment is a touch screen. The display screen 194 may integrate a touch sensor 180K. The touch sensor 180K can also be referred to as a "touch panel." That is, the display screen 194 may include a display panel and a touch panel, with the touch sensor 180K and the display screen 194 forming a touch screen, also called a "touchscreen." The touch sensor 180K is used to detect touch operations applied to or near it. After the touch sensor 180K detects a touch operation, it can be passed to the upper layer by the kernel layer driver (such as the TP driver) to determine the type of touch event, thereby realizing different functions. For example, when charging an electronic device, one can long-press the charging icon on the display interface to activate fast charging.
[0116] 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.
[0117] The power management module 141 is used to connect 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 to power the processor 110, internal memory 121, external memory, display 194, camera 193, and wireless communication module 160, etc.
[0118] The power management module 141 can also be used to 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 can 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 can also be located in the same device.
[0119] The wireless communication function of electronic device 100 can be realized through devices such as antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor.
[0120] The mobile communication module 150 can provide wireless communication solutions, including 2G / 3G / 2G / 5G / 6G, for use on electronic devices 100.
[0121] The modem processor may include a modulator and a demodulator. The modulator modulates a low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates a received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through audio devices (e.g., speaker 170A, receiver 170B) or displays images or videos through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.
[0122] Similar to the mobile communication module 150, the wireless communication module 160 can also provide a wireless communication solution for use on the electronic device 100, such as at least one of the following: wireless local area networks (WLAN), Bluetooth (BT), Bluetooth Low Energy (BLE), ultra-wideband (UWB), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technology.
[0123] The external storage interface 120 can be used to connect an external memory card, such as a secure digital (SD) card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, images, and video files can be stored on the external memory card.
[0124] Internal memory 121 can be used to store computer executable program code, which includes instructions. Internal memory 121 may include a program storage area and a data storage area.
[0125] The fingerprint sensor 180H is used to collect fingerprints. The electronic device 100 can use the collected fingerprint characteristics to perform functions such as unlocking, accessing application locks, taking photos, and answering calls.
[0126] 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 PMIC Glink channel.
[0127] Button 190 includes a power button and volume buttons. Button 190 can be a mechanical button or a touch button. Electronic device 100 can receive button input signals and implement functions related to the button input signals.
[0128] Furthermore, various types of operating systems run on these components. Examples include Android, iOS, Symbian, BlackBerry, Linux, and Windows. This is merely illustrative and not intended to be limiting. Different applications, such as any type of input method application, can be installed and run on these operating systems.
[0129] The communication method provided in this application embodiment can be implemented in an electronic device 100 having the above-described hardware structure.
[0130] The structure of the electronic device 100 involved in the embodiments of this application has been briefly described above. The software structure involved in the embodiments of this application will be briefly described below. Please refer to FIG3, which is a software structure block diagram of an electronic device shown in an exemplary embodiment of this application.
[0131] As shown in Figure 3, the software system of electronic device 100 may include a main system running on the AP side and a subsystem running on the ADSP side. Additionally, for ease of explanation, Figure 3 also shows the hardware layer 200 of electronic device 100.
[0132] The architecture of the main system on the AP side will be described below. For example, the main system running on the AP side can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses a layered architecture Android system as an example for illustration.
[0133] 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 from top to bottom into an application layer 210, an application framework layer 220, a hardware abstraction layer 230, and a kernel layer 240.
[0134] Application layer 210 may include a series of application packages. As shown in Figure 3, the application packages may include applications such as fitness and health, music, and gallery. Of course, application layer 210 may also include applications such as camera, calendar, call, map, navigation, WLAN, Bluetooth, video, and SMS, which are not shown in Figure 3.
[0135] 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.
[0136] As shown in Figure 3, 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.
[0137] In addition, the application framework layer 220 may also include a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, etc., which are not shown in Figure 3.
[0138] The window manager is used to manage window applications. It can obtain the screen size, determine if a status bar is present, lock the screen, and capture screenshots, among other things.
[0139] 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.
[0140] 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.
[0141] The phone manager is used to provide communication functions for electronic device 100. For example, it manages call status (including connection and disconnection).
[0142] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.
[0143] 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.
[0144] The hardware abstraction layer (HAL) 230 is used to abstract and encapsulate the hardware functions provided by the electronic device. As shown in Figure 3, 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) running on the AP side.
[0145] The sensor hardware abstraction layer provides a unified sensor data interface to upper layers (such as the application framework layer 220) to provide sensor data and related services. The audio hardware abstraction layer provides a unified audio data interface to upper layers to provide audio processing services. The charging hardware abstraction layer provides a unified charging control interface to upper layers to provide charging-related data and services, including power data.
[0146] Kernel layer 240 is the layer between hardware and software. As shown in Figure 3, kernel layer 240 may include an identifier addition module, a packaging module, a timeout reason determination module, an acknowledgment module, and may also include a driver module and a PMIC Glink module.
[0147] The identifier addition module is used to add unique identification information (also known as unique identifiers) to service data on the AP side. This service data can include service instructions / commands, service requests, service content, etc.
[0148] The encapsulation module is used to encapsulate business data after adding unique identification information.
[0149] The timeout cause determination module is used to determine the timeout cause based on the timeout information sent by the ADSP, that is, to accurately locate the root cause of the AP's data transmission and reception timeout.
[0150] The response module is used to wake up the AP side's waiting response event and determine whether the AP side's waiting response event has timed out. If the AP side's waiting response event has not timed out, it returns a success status to the application layer 210; if the AP side's waiting response event has timed out, it triggers the PMIC Glink module to resend the service data to the ADSP side within the allowed number of retransmissions of service data; if the number of retransmissions of service data has been reached and the AP side's waiting response event has still timed out, it returns a failure status to the application layer 210.
[0151] The driver module and PMIC Glink module can be referred to the relevant descriptions in the embodiment corresponding to Figure 1, which will not be repeated here.
[0152] Of course, kernel layer 240 can also include display drivers, camera drivers, audio drivers, etc., as shown in Figure 3.
[0153] The architecture of the ADSP-side subsystem is described below. In one possible implementation, the subsystem running on the ADSP side can be a Real-Time Operating System (RTOS). The RTOS can also adopt a layered architecture. Specifically, the ADSP can include, from top to bottom, an application layer 250, a middleware layer 260, a kernel layer 270, and a driver layer 280.
[0154] 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.
[0155] 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, mixing, reverb, compression, expansion, and synchronization. Audio processing middleware can work in conjunction with audio codecs in hardware layer 200 to achieve high-quality audio processing.
[0156] 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, feature extraction, data conversion, data compression, and data caching. The sensor processing middleware can improve the quality and availability of sensor data, providing more valuable information for upper-layer applications and the AP side.
[0157] 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.
[0158] The kernel layer 270 is used to implement task scheduling, interrupt handling, memory management, synchronization, and communication in the subsystems on the ADSP side. In this embodiment, the kernel layer 270 may include an interrupt service module, a service processing module, a restart module, and may also include a PMIC Glink module.
[0159] The interrupt service module is used to receive service data sent by the AP side, and when it detects that the receive queue in the ADSP is not full, it stores the service data into the receive queue and adds an enqueue time to the service data.
[0160] The interrupt service module is also used to determine whether there is identical business data in the receiving queue based on the identification information of the business data; if there is identical business data in the receiving queue, the business data is discarded.
[0161] The interrupt service module is also used to store the service data into a preset discard queue and add a discard time to the service data if there is no corresponding identical service data in the receive queue and the receive queue is full.
[0162] The interrupt service module is also used to detect whether the receive queue in the ADSP is not full if there is no corresponding service data in the receive queue. If the receive queue is not full, the service data is stored in the receive queue and an enqueue time is added to the service data.
[0163] The business processing module is used to process business data and record the start time of the corresponding business data; the business processing module is also used to record the end time of the corresponding business data when the business data is completed.
[0164] The business processing module is also used to extract business data from the receiving queue; start a preset timeout timer; obtain the start processing time corresponding to the business data; and call the business processing logic corresponding to the business data to perform business processing.
[0165] The restart module is used to call the interrupt callback function to restart the ADSP if the timeout timer detects that the service processing has timed out.
[0166] The PMIC Glink module is used to send timeout information to the AP. This timeout information includes the queuing time, start processing time, and end processing time of the business data. This timeout information is used by the AP to determine the reason for the timeout.
[0167] The driver layer 280 provides drivers for various hardware devices in the ADSP-side subsystem, enabling access and control of the hardware. Driver layer 280 may include sensor drivers, audio codec drivers, fuel gauge drivers, etc.
[0168] Referring to Figure 3, the hardware layer 200 may include hardware devices such as sensors, audio codecs, and fuel gauges. Among them, sensors may include 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.
[0169] For ease of understanding, the following embodiments of this application will take an electronic device with the structure shown in FIG1 and FIG2 as an example, and in conjunction with the accompanying drawings and application scenarios, will specifically illustrate the communication method provided by the embodiments of this application.
[0170] Please refer to Figure 4, which is a flowchart illustrating a communication method provided in an embodiment of this application. The method includes:
[0171] S101 and AP send service data to ADSP.
[0172] For example, the services of the AP in the embodiments of this application may include services that require sensor data interaction, services that require audio data interaction, services that require power data interaction, etc.
[0173] For example, services requiring sensor data interaction may include health monitoring, motion monitoring, automatic screen rotation, smart home control, OEM services, etc.; services requiring audio data interaction may include audio playback, headphone (wired and wireless) testing, etc.; services requiring power data interaction may include charging management, power monitoring, fast charging, UCSI, QTI Battery, Charger, etc.
[0174] Business data may include business instructions / commands, business requests, business content data (such as audio data), metadata, configuration parameters, system status information, network data, etc. This is only an example and is not a limitation.
[0175] For example, in response to a user's operation on an electronic device, corresponding business data is generated. User operations on an electronic device may include rotating the device, clicking controls in a music application (such as play or pause controls), connecting or disconnecting a charging cable, adjusting battery mode, connecting or disconnecting headphones, etc. This is merely an example and is not intended to be limiting.
[0176] Optionally, in one possible implementation, the electronic device can automatically perform multiple operations, and in the process, it can also generate business data. For example, it can automatically perform battery health management (adjusting charging cycles, monitoring battery health status, etc.), automatically adjust charging modes (fast charging mode, slow charging mode), periodically acquire sensor data, etc. This is only for illustrative purposes and is not intended to limit the scope.
[0177] Taking the application that triggers the application layer to generate business data as an example, the business data generated by the application is passed to the driver module in the AP kernel layer. The Pmic_glink_write driver runs in the PMIC Glink module of the AP, writes the business data in the driver module into the PMIC Glink channel, and then uses the PMIC Glink channel to send the corresponding business data of the AP to the ADSP.
[0178] Alternatively, in one possible implementation, the service data generated by the application can be passed to the response module in the AP kernel layer, the response module sends the service data to the PMIC Glink module, and the PMIC Glink module sends the service data corresponding to the AP to the ADSP.
[0179] S102, ADSP receives service data.
[0180] S103, ADSP detects whether the receive queue is not full.
[0181] For example, the PMIC Glink module in the ADSP receives service data sent by the AP. When the service data arrives, the PMIC Glink module generates an interrupt signal. The interrupt service module detects the interrupt signal and triggers the execution of the interrupt service routine (ISR), or in other words, triggers the execution of the interrupt service program.
[0182] The status of the receive queue is detected using the interrupt service module in the ADSP to determine if the receive queue is not full. For example, a variable (such as a counter) is defined in the receive queue's data structure to track the current number of elements in the receive queue (i.e., the amount of service data). The ADSP-side subsystem or interrupt service module creates the receive queue and initializes the status variable during initialization. The ISR can access and check the status variable of the receive queue and determine if its value is less than the maximum capacity of the receive queue (i.e., the preset amount of service data that can be stored). If the result is that the status variable value is less than the maximum capacity, the receive queue is determined to be not full; if the result is that the status variable value is greater than or equal to the maximum capacity, the receive queue is determined to be full.
[0183] S104: ADSP detects that the receive queue is not full, stores the service data into the receive queue, and adds an enqueue time to the service data.
[0184] When the receive queue is detected to be not full, it means that there is still space available to continue storing business data. For example, the interrupt service module performs an enqueue operation, such as storing the business data into the receive queue according to the pre-set data structure of the receive queue.
[0185] It is worth noting that, in this embodiment of the application, when storing service data into the receiving queue, the current time is obtained as a timestamp, and the timestamp is added to the service data stored in the receiving queue, or in other words, an enqueue time is added to the service data. For example, the ISR can generate a timestamp for the service data to record the specific time when the service data is enqueued; or, for another example, the current time (i.e., the enqueue time of the service data) can be determined by a timer or clock service provided by the system.
[0186] In one possible implementation, a timestamp or the current time (i.e., the enqueue time of the business data) is directly added to the data structure of the business data stored in the receiving queue.
[0187] Optionally, in one possible implementation, the business data and its corresponding timestamp (or enqueue time) are encapsulated to obtain encapsulated business data, and the encapsulated business data is stored in the receiving queue.
[0188] S105, ADSP detects that the receive queue is full and stores the service data into the preset discard queue.
[0189] When the receive queue is detected to be full, it indicates that there is no remaining space in the receive queue to continue storing service data. For example, the interrupt service module performs a discard operation, such as storing the service data into the discard queue according to a pre-configured data structure. This discard queue can be created during the initialization of the ADSP-side subsystem or the interrupt service module.
[0190] Optionally, in one possible implementation, when discarding service data (i.e., when storing the service data in the discard queue), this embodiment of the application obtains the current time as a timestamp and adds the timestamp to the service data stored in the discard queue, or in other words, adds a discard time to the service data. For example, the ISR can generate a timestamp for the service data to record the specific time when the service data is discarded; or, for another example, the discard time of the service data can be determined by a timer or clock service provided by the system.
[0191] For example, a timestamp or discard time can be directly added to the data structure of the business data stored in the discard queue. Alternatively, the business data and its corresponding timestamp (or discard time) can be encapsulated to obtain encapsulated business data, which can then be stored in the discard queue.
[0192] In this implementation, adding a discard time to the discarded business data can provide accurate information about the discarded business data, making it easier to determine the waiting time of the business data in the discard queue.
[0193] S106, ADSP processes business data and records the start processing time corresponding to the business data.
[0194] For example, a service processing program can run in the service processing module of the ADSP to extract service data to be processed from the receiving queue.
[0195] Specifically, first check if the receive queue is empty. For example, you can check if the current size of the receive queue is 0 to determine if the receive queue is empty. If the current size of the receive queue is 0, then the receive queue is considered empty; if the current size of the receive queue is not 0, then the receive queue is considered not empty.
[0196] For example, the emptiness of the receive queue can be determined by checking if the head pointer and tail pointer are equal. The head pointer points to the first data item in the receive queue, and the tail pointer points to the position after the last data item. If the head and tail pointers are equal, the receive queue is considered empty; if they are not equal, the receive queue is considered not empty.
[0197] For example, check if the variable representing the number of elements in the receive queue is 0 to determine if the receive queue is empty. If the variable is 0, the receive queue is considered empty; if the variable is not 0, the receive queue is considered not empty.
[0198] When the receive queue is detected to be empty, continue polling until the receive queue is detected to be non-empty.
[0199] When the receive queue is detected to be non-empty, a dequeue operation is performed on the service data in the receive queue. For example, following a first-in, first-out (FIFO) approach, the service processing program retrieves the service data from the head of the receive queue. Optionally, after retrieving the service data, parameters such as the head pointer, the size of the receive queue, and variables can be updated.
[0200] It is worth noting that, in this embodiment of the application, when extracting service data from the receiving queue, the current time is obtained and recorded as the start processing time corresponding to the service data. Optionally, a field is pre-set in the data structure of the service data to store the start processing time, and after obtaining the start processing time, the start processing time is recorded in the preset field.
[0201] It is understood that in this embodiment of the application, when storing business data in the receiving queue, an enqueue time is added to the business data. Therefore, when retrieving the business data from the receiving queue, the enqueue time of the business data can be obtained directly.
[0202] S107. The ADSP completes the processing of the business data and records the corresponding end processing time of the business data.
[0203] For example, different business processing functions are invoked to process the business data based on its different business types. For instance, if the business type of the business data is UCSI, the UCSI business processing function is invoked; if the business type of the business data is QTI Battery, the QTI Battery business processing function is invoked; if the business type of the business data is Charger, the Charger business processing function is invoked, and so on.
[0204] It is worth noting that, in this embodiment of the application, when processing business data, the current time is obtained and recorded as the end processing time corresponding to the business data. Optionally, another field is pre-set in the data structure of the business data to store the end processing time, and after obtaining the end processing time, the end processing time is recorded in the preset other field.
[0205] S108. If the processing of business data times out, the ADSP will send the timeout information to the AP.
[0206] For example, processing timeouts for business data can include timeouts for processing individual business data, i.e., timeouts for processing business data corresponding to a single business, and can also include timeouts caused by too much business data received by the receiving queue. For example, the time difference between the end of processing time and the enqueue time is calculated and denoted as the first time difference; the time difference between the end of processing time and the start of processing time is calculated and denoted as the second time difference.
[0207] When the first time difference exceeds a first preset threshold, it indicates that the time from when the business data is enqueued to when processing is completed is too long. The reason for this excessive time is that the number of business data received by the receive queue exceeds the preset reception limit. In simpler terms, when the ADSP receives an interrupt signal, it pauses the current processing operation and executes the interrupt service routine associated with that interrupt signal. Therefore, when there is too much business data received in the receive queue, the time from when the business data is enqueued to when processing is completed will increase.
[0208] The first preset threshold can be set and adjusted according to actual conditions. For example, the first preset threshold can be 2 seconds, 3 seconds, 4 seconds, etc. This is only an example and is not a limitation. Similarly, the preset number of receptions can also be set and adjusted according to actual conditions.
[0209] When the second time difference exceeds the second preset threshold, it indicates that the processing time for a single business data item is too long. The reasons for this excessive processing time may include waiting to acquire hardware data, such as data from an integrated circuit (I2C) device, a serial peripheral interface (SPI) device, or sensor data.
[0210] Alternatively, another reason for the excessively long processing time for a single business data item may be waiting for other processes (or threads) to release resources, also known as waiting for a lock. For example, processing the business data requires acquiring a lock, but if that lock is held by another business process, then it is necessary to wait for that other business process to release the lock.
[0211] Alternatively, the reason why the processing time for a single business data item is too long may also be due to insufficient performance of electronic devices, such as outdated hardware or insufficient processor processing power.
[0212] The second preset threshold can be set and adjusted according to the actual situation. For example, the second preset threshold can be 1 second, 1.5 seconds, 2 seconds, etc. This is only an example and is not limited.
[0213] For example, if it is determined that the processing of business data has timed out, the ADSP records the enqueue time, start processing time and end processing time of the business data as timeout information and sends it to the AP through the PMIC Glink module.
[0214] In one implementation, the enqueue time of the service data is extracted from the receiving queue, and the enqueue time, along with the start and end processing times recorded when processing the service data, are sent to the AP as timeout information together with the service data.
[0215] Optionally, in one possible implementation, the AP adds identification information to the service data when sending it, and sends the identification information, queuing time, start processing time, and end processing time of the service data as timeout information to the AP.
[0216] Optionally, in another possible implementation, since the enqueue time is added directly based on the data structure of the business data stored in the receiving queue, and the start and end processing times are also stored in the fields of the business data data structure, the business data carrying the enqueue time, start processing time, and end processing time can be directly sent to the AP as timeout information.
[0217] It should be understood that if the processing of business data does not time out, the business processing flow will be executed cyclically. For example, if a first time difference is detected to be less than or equal to a first preset threshold, and a second time difference is detected to be less than or equal to a second preset threshold, the business processing flow will be executed cyclically.
[0218] S109, AP determines the timeout reason based on the timeout information.
[0219] After sending service data, the AP wakes up the corresponding waiting response event through the response module and checks whether the waiting response event has timed out, that is, whether the waiting to receive the response has timed out. In simpler terms, it checks whether the waiting to receive the response data from the ADSP has timed out.
[0220] For example, it is detected whether the waiting time for receiving a response is greater than a third preset threshold. The second preset threshold can be set and adjusted according to the actual situation. For example, the second preset threshold can be 1 second, 1.5 seconds, 2 seconds, etc. This is only an example and is not limited thereto.
[0221] In this embodiment, a third preset threshold of 1 second is used as an example. If the waiting time for receiving a response is less than or equal to 1 second, that is, if the AP receives the response data (such as the battery value) sent by the ADSP within 1 second, it proves that the waiting time for receiving the response data from the ADSP has not exceeded the timeout, and then an indication message indicating successful service is returned to the application.
[0222] Optionally, in one possible implementation, if the timeout for receiving response data from the ADSP occurs, it can also be checked whether a preset number of retries has been exceeded. Here, the number of retries represents the number of times the AP retransmits the service data. The number of retries can be reasonably set and adjusted according to actual conditions; for example, it can be set to 3, 5, 8, 10, etc. This is only an example and is not a limitation.
[0223] For example, if the retry count has not been exceeded, the AP sends the service data to the ADSP again through the PMIC Glink module. After resending the service data, if a timeout is still detected while waiting to receive the response data from the ADSP, the AP continues to check if the retry count has been exceeded. If the retry count has not been exceeded, the AP sends the service data to the ADSP again through the PMIC Glink module until the AP receives the response data sent by the ADSP, or if the retry count is exceeded, the AP returns an indication message indicating service failure to the application.
[0224] It should be understood that for the AP side, if it times out while waiting to receive response data from the ADSP side, or returns a failure status, it is usually due to the ADSP side timeout in processing service data. The ADSP side will send timeout information to the AP side, and the AP side will determine the cause of the timeout based on the received timeout information.
[0225] For example, the timeout information includes the queuing time, start processing time, and end processing time corresponding to the business data. The timeout reason determination module in the AP determines a first time difference and / or a second time difference based on the timeout information, and determines the timeout reason based on the first time difference and / or the second time difference.
[0226] For example, a first time difference is determined based on the end processing time and the enqueue time, and a second time difference is determined based on the end processing time and the start processing time. When the first time difference is greater than a first preset threshold, it indicates that the time from enqueueing to processing completion of the service data is too long, and the timeout reason is determined to be that the number of service data received by the ADSP exceeds the preset reception quantity. When the second time difference is greater than a second preset threshold, it indicates that the time from the start processing to the end processing of a single service data is too long, and the timeout reason is determined to be that the ADSP timed out processing a single service data. When both the first time difference and the second time difference are greater than the first preset threshold, the timeout reason is determined to be that the number of service data received by the ADSP exceeds the preset reception quantity, and the ADSP timed out processing a single service data.
[0227] In this implementation, the ADSP adds an enqueue time to the business data when enqueuing it, records the start time of processing the data, and records the end time when processing is complete. If the ADSP times out processing business data, it sends a timeout message to the AP. The AP can calculate the time difference based on the enqueue and end times in the timeout message, and also calculate the time difference based on the start and end times. By using these different time differences, the root cause of the AP's data transmission timeout can be accurately located. Specifically, it can be determined that the AP's data transmission timeout is due to the ADSP receiving more business data than the preset reception limit, or the ADSP timing out a single business data instance, or both. Accurately locating the root cause of the AP's data transmission timeout helps developers better resolve timeout faults. For example, the AP can be controlled to prevent it from frequently sending the same business data when it hasn't received a response from the ADSP, effectively preventing the ADSP from receiving too much business data in a short period and ensuring the smooth execution of the business processing flow.
[0228] In related technologies, when an AP sends service data to an ADSP, the ADSP stores all the service data sent by the AP in its receive queue. Only when the receive queue is full will the service data sent by the AP be discarded. If the AP frequently sends the same service data to the ADSP after the data transmission and reception timeout, it will cause the ADSP's receive queue to overflow, leading to ADSP blocking.
[0229] In view of this, this application provides a communication method based on the embodiment corresponding to Figure 4. Before the AP sends the service data to the ADSP, a TOKEN identifier (i.e., identification information) is added to the service data. Then, the service data with the added identification information is encapsulated to obtain encapsulated service data, which is then sent to the ADSP. When the ADSP receives the service data sent by the AP, it searches the receive queue for identical service data based on the identification information carried by the service data. If identical service data exists in the receive queue, the service data is discarded.
[0230] This implementation method has two advantages. First, it can filter out duplicate service data sent repeatedly by the AP, thereby effectively preventing a large amount of duplicate service data from being stored in the ADSP's receive queue, preventing the ADSP's receive queue from overflowing, and reducing the risk of the ADSP being blocked due to repeatedly receiving the same service data. Second, it reduces the amount of data in the receive queue, improves the efficiency of the ADSP in processing service data, improves the stability of communication between the AP and the ADSP, and by reducing unnecessary data transmission and processing, the ADSP can respond faster, thereby reducing the occurrence of AP data transmission and reception timeouts.
[0231] For ease of understanding, the communication methods executed on the AP side and ADSP side are described below with reference to the accompanying drawings. The communication method executed on the AP side is described first. Please refer to Figure 5, which is a flowchart illustrating a method for sending service data provided in this embodiment of the application. The method includes:
[0232] S201 and AP add identification information to business data.
[0233] S202, AP encapsulates and adds identification information to the business data.
[0234] Identification information may include any one or any combination of serial numbers, randomly generated unique values, hash values, etc.
[0235] For example, initialize the random number generator to ensure that each generated random number is unpredictable. For each piece of business data, use the random number generator to generate a unique random value, which can be a long integer, a universally unique identifier (UUID), or other form of unique identifier. The AP encapsulates the business data and its corresponding random number into a new data packet.
[0236] For example, a sequence number counter is initialized for each piece of service data to be sent. The AP appends the current value of the sequence number counter as identification information to the service data, and then encapsulates the service data and its corresponding sequence number into a new data packet. Optionally, after encapsulating the data packet, the sequence number counter is incremented to generate new identification information for the next piece of service data.
[0237] S203 and AP send the encapsulated service data to ADSP.
[0238] The AP uses the PMIC Glink module to send service data containing identification information to the ADSP.
[0239] Alternatively, in one possible implementation, the encapsulated data packet can be converted into a format suitable for PMICGlink channel transmission, and the AP sends the converted data packet to the ADSP.
[0240] In this implementation, the service data sent by the AP to the ADSP carries identification information. The ADSP can then use this identification information to search its receive queue for identical service data. If identical service data is found in the receive queue, it is discarded. This filters out duplicate service data sent multiple times by the AP, effectively preventing a large amount of duplicate service data from accumulating in the ADSP's receive queue, thus preventing queue overflow and reducing the risk of ADSP blocking due to repeated reception of the same service data.
[0241] S204. AP checks if the timeout for receiving a response has occurred.
[0242] After sending the encapsulated service data, the AP checks whether the timeout for waiting to receive the response has occurred, that is, whether the timeout for waiting to receive the response from the ADSP has occurred. In simple terms, it checks whether the timeout for waiting to receive the response data from the ADSP has occurred.
[0243] S205. Confirm that the timeout for receiving the response has not expired, and return to the success status.
[0244] For example, the system checks whether the waiting time for receiving a response is greater than a third preset threshold. In this embodiment, the third preset threshold is 1 second. If the waiting time for receiving a response is less than or equal to 1 second, that is, the AP receives the response data sent by the ADSP within 1 second, it proves that the waiting time for receiving the response data from the ADSP has not timed out, and then returns an indication message indicating successful service to the application.
[0245] S206. Determine if the timeout for receiving a response has occurred, and check if the number of retries has been exceeded.
[0246] S207. If the number of retries has been exceeded, return a failure status.
[0247] If the waiting time for a response exceeds 1 second, meaning the AP does not receive the response data sent by the ADSP within 1 second, it indicates a timeout in waiting for the ADSP's response data, and the system checks whether the retry count has been exceeded. The retry count represents the number of times the AP retransmits the encapsulated service data.
[0248] For example, if the number of retries has not been exceeded, the process returns to step S203, whereby the AP resends the encapsulated service data to the ADSP. It is worth noting that when the AP resends the encapsulated service data to the ADSP, it can directly send the encapsulated service data to the ADSP without adding identification information or encapsulating the original service data, thus improving the efficiency of resending the service data.
[0249] Optionally, in one possible implementation, after retransmitting the encapsulated service data, if a timeout is still detected while waiting to receive the response data from the ADSP, the system continues to check if the retry count has been exceeded. If the retry count has not been exceeded, the AP retransmits the encapsulated service data to the ADSP again until the AP receives the response data sent by the ADSP; or, if the retry count is exceeded, an indication message indicating service failure is returned to the application.
[0250] In this implementation, on the one hand, if the wait for the ADSP's response data times out, it does not immediately return a failure status, but instead retransmits the encapsulated service data. If a momentary failure causes the AP to time out its data transmission, data transmission can be achieved by retransmitting the encapsulated service data, thus improving the reliability of data transmission. On the other hand, retransmitting the encapsulated service data within a limited number of retries avoids problems such as resource exhaustion, system overload, and channel congestion caused by infinitely repeating service data.
[0251] Optionally, in one possible implementation, when it is determined that the AP has timed out while waiting to receive a response, and / or the AP returns a failure status, detailed information related to the timeout is recorded in the kernel log, such as the timeout point, timeout duration, identification information of the service data, transmission time, number of retries, result of each retry, system status of the AP and ADSP at the time of the timeout, communication parameters between the AP and ADSP, error code, diagnostic information, system configuration, etc. This implementation allows the AP to accurately determine the root cause of data transmission / reception timeouts based on the information recorded in the kernel log, thereby addressing the timeout problem in a targeted manner.
[0252] The communication method executed on the ADSP side will be described below. Please refer to Figure 6, which is a schematic diagram of another queuing process provided in an embodiment of this application. The method includes:
[0253] S301, ADSP receives interrupt signals.
[0254] For example, the PMIC Glink module in the ADSP receives encapsulated service data sent by the AP. When the encapsulated service data arrives, the PMIC Glink module generates an interrupt signal. The interrupt service module detects the interrupt signal and triggers the execution of the interrupt service routine (ISR), or in other words, triggers the execution of the interrupt service program.
[0255] S302 and ADSP detect whether there is identical business data based on the identification information.
[0256] For example, the ADSP parses the received encapsulated service data to obtain the identification information corresponding to the service data. It then searches the receive queue for identical identification information. If it finds such information, it proves that the service data corresponding to the identical identification information in the receive queue is the same service data; otherwise, it proves that the same service data does not exist in the receive queue.
[0257] Optionally, an index structure (such as a hash table, database, or in-memory data structure) can be maintained to store the identification information of the business data already stored in the receiving queue. Using the parsed identification information as the key, the index structure is searched to determine if identical business data exists; that is, to check if there is business data identical to the currently received business data. If no identical business data exists, its identification information is added to the index structure for subsequent queries of the same business data.
[0258] S303 and ADSP detected the existence of identical service data and discarded the service data.
[0259] For example, if the receive queue already contains the same service data as the service data currently being sent by the AP (i.e., the same service data corresponding to the service data currently being sent by the AP), then the service data currently sent by the AP is discarded. In other words, in this case, the service data currently sent by the AP will not be stored in the receive queue. This filters out duplicate service data sent multiple times by the AP, effectively preventing a large amount of duplicate service data from being stored in the ADSP's receive queue, preventing the ADSP's receive queue from overflowing, and reducing the risk of the ADSP being blocked due to repeatedly receiving the same service data. Furthermore, this reduces the amount of data in the receive queue, improves the efficiency of the ADSP in processing service data, and enhances the stability of communication between the AP and the ADSP. By reducing unnecessary data transmission and processing, the ADSP can respond faster, thereby mitigating the occurrence of AP data transmission / reception timeouts.
[0260] S304 and ADSP detected that no identical service data existed and checked whether the receive queue was not full.
[0261] For example, if there is no service data in the receiving queue that is the same as the service data currently being sent by the AP, then the service data currently being sent by the AP needs to be stored in the receiving queue. In order to ensure that the service data can be successfully stored in the receiving queue, the receiving queue is first checked to see if it is not full.
[0262] S305 and ADSP detect that the receive queue is not full, store the service data into the receive queue, and add an enqueue time to the service data.
[0263] The description of step S305 can be found in step S104, and will not be repeated here. It is worth noting that the business data here refers to the encapsulated business data, that is, business data carrying identification information.
[0264] In this implementation, an enqueue time is added to the service data stored in the receiving queue, so that the AP can determine the root cause of the timeout based on the enqueue time.
[0265] S306 and ADSP detect that the receive queue is full, store the service data in the discard queue, and add a discard time to the service data.
[0266] The description of step S306 can be found in step S105, and will not be repeated here. It is worth noting that in this implementation, adding a discard time to the discarded business data provides accurate information about the data's discarding, facilitating the determination of the data's waiting time in the discard queue.
[0267] When ADSP processes business data, it may experience serious failures. In related technologies, when ADSP experiences serious failures, it cannot be recovered in time, resulting in abnormal business data processing flow, exacerbating the timeout of AP data transmission and reception, and seriously affecting the interaction between AP and ADSP.
[0268] In view of the above, this application provides a communication method. Based on the foregoing embodiments, when the ADSP executes the service processing flow, a preset timeout timer is first started to monitor whether the service processing has timed out. If the service processing has not timed out, the timeout timer is turned off and the end processing time corresponding to the service data is recorded. If the service processing has timed out, the ADSP is triggered to call an interrupt callback function. The interrupt callback function is used to restart the ADSP.
[0269] In this implementation, a timeout timer is added to monitor whether the business processing times out. If a timeout occurs, an interrupt callback function is triggered to restart the ADSP, thus preventing the ADSP from freezing and becoming unrecoverable due to business processing timeout.
[0270] Please refer to Figure 7, which is a flowchart illustrating a method for processing business data according to an embodiment of this application. The method includes:
[0271] S401 and ADSP perform task initialization.
[0272] Task initialization refers to the process by which the ADSP prepares its operating environment before processing business data for the first time. In the embodiments of this application, task initialization may include establishing a receive queue, establishing a discard queue, initializing the state variables in the receive queue, initializing the sequence number counter, initializing the random number generator, initializing various data structures required for processing business data, initializing the timeout timer, etc. This is only an illustrative example and is not intended to limit the scope of the application.
[0273] S402, ADSP detects whether the receive queue is empty.
[0274] It's worth noting that the business processing flow can be executed through a business processing program. The business processing program and the interrupt service routine run separately; that is, the business processing program continuously loops through the process of processing business data, while the interrupt service routine continuously loops through the enqueue process. Therefore, to ensure smooth processing of business data, the business processing program will first check if the receive queue is empty.
[0275] If the receive queue is detected to be empty, it means there is no pending service data. The status of the receive queue will continue to be monitored, i.e., the receive queue will continue to be checked for emptiness. If the receive queue is detected to be not empty, step S403 will be executed.
[0276] S403. When the receive queue is detected to be non-empty, extract the service data from the receive queue.
[0277] For example, when the receive queue is detected to be non-empty, it indicates that there is business data to be processed, and a dequeue operation is performed on the business data in the receive queue. For instance, following a first-in-first-out (FIFO) approach, the business processing program retrieves business data from the head of the receive queue.
[0278] S404, ADSP starts the preset timeout timer.
[0279] For example, the timeout timer is initialized beforehand, including determining the timeout duration, registering the corresponding callback function, and configuring logic for handling timeout events. The timeout timer is then started by calling the function or interface that initiates it.
[0280] S405 and ADSP begin processing business data and record the start time of the corresponding business data.
[0281] In one possible implementation, when processing business data begins, the current time is obtained and recorded as the start time for that business data. In another possible implementation, since processing of business data typically begins as soon as it is retrieved from the receiving queue, the current time is obtained and recorded as the start time for that business data when it is retrieved from the receiving queue.
[0282] S406, ADSP retrieves the queuing time of business data.
[0283] In this embodiment of the application, when storing business data in the receiving queue, an enqueue time is added to the business data. Therefore, when retrieving the business data from the receiving queue, the enqueue time of the business data can be obtained directly.
[0284] S407, ADSP calls the business processing function to perform business processing.
[0285] For example, different business processing functions are invoked to process the business data according to different business types. For details, please refer to the relevant description in step S107 above, which will not be repeated here.
[0286] S408, ADSP disable timeout timer.
[0287] S409, ADSP records the end processing time corresponding to the business data.
[0288] During the process of calling the business processing function to process business data, a timeout timer monitors whether the business processing process times out, that is, whether the processing time exceeds the preset timeout duration. The timeout duration can be set and adjusted according to actual needs; for example, it can be set to 5 seconds, 6 seconds, 8 seconds, etc. This is only an example and is not a limitation.
[0289] If the processing time does not exceed the preset timeout period, it proves that the processing of the business data has been completed. Obtain the current time and record it as the end processing time for the business data.
[0290] If the processing time exceeds the preset timeout period, it indicates that the corresponding business data has not been completed. This may be because the business processing requires waiting for other processes (or threads) to release resources, also known as waiting for a lock. For example, when processing business data related to charging, it is necessary to read I2C data, which requires locking the I2C. If another task has already locked the I2C, it can only wait for the other task to release the lock. If the other task encounters an unexpected situation and fails to release the lock normally, a deadlock occurs, causing the ADSP to freeze and become unrecoverable.
[0291] Alternatively, the reasons for the processing time exceeding the timeout period may also include insufficient performance of electronic devices (such as outdated hardware or insufficient processor processing power), service interruption, system crash, resource exhaustion, software failure, abnormal termination, timeout of a certain operation, processing blockage, function stagnation, hardware lockout, etc.
[0292] In this situation, since we have enabled the timeout timer, when the timeout timer monitors for a timeout, it will trigger the call to the interrupt callback function, which will then restart the ADSP and restore the ADSP to normal operation.
[0293] S410 and ADSP detect whether the processing of business data has timed out.
[0294] The description of step S410 can be found in step S108, and will not be repeated here. It is worth noting that the timeout for processing business data here differs from the timeout monitored by the timeout timer. Here, business data processing timeout means that the business data is eventually processed, and its processing time is less than the timeout duration, but the first time difference is greater than the first preset threshold, and / or the second time difference is greater than the second preset threshold. Timeout monitored by the timeout timer, on the other hand, means that the processing time exceeds the preset timeout duration, and the ADSP freezes before the business data is fully processed, requiring an ADSP restart to resume processing the business data.
[0295] S411. If a timeout is detected in processing business data, the timeout information will be sent to the AP.
[0296] The description of step S411 can be found in step S108, and will not be repeated here. If the processing of business data has not timed out, then return to step S402.
[0297] In this implementation, a timeout timer is added to monitor whether the business processing times out. If a timeout occurs, an interrupt callback function is triggered to restart the ADSP, which can restore the process of processing business data and improve the reliability of communication between the AP and the ADSP.
[0298] Please refer to Figure 8, which is a flowchart illustrating a method for restarting an ADSP according to an embodiment of this application. The method includes:
[0299] S501. If the timeout timer detects a timeout in the service processing, the ADSP will be triggered to call the interrupt callback function.
[0300] S502, restart ADSP using the interrupt callback function.
[0301] For example, an interrupt callback function is pre-registered in the timeout timer to ensure that the interrupt callback function is invoked when the timeout timer expires (or when the business processing process is detected to have timed out). The interrupt callback function then calls a restart function or executes a restart command to restart the ADSP. For instance, the interrupt callback function can call the fatal error (FATAL) interface to restart the ADSP.
[0302] In this implementation, if the ADSP encounters a serious fault or crashes, preventing it from continuing to execute tasks, an interrupt callback function is triggered by a timeout timer to restart the ADSP. This can restore the process of processing business data and improve the reliability of communication between the AP and the ADSP.
[0303] Optionally, in one possible implementation, steps S503 and S504 may be included after step S502. Please refer to Figure 9, which is a flowchart illustrating a method for sending a dump file according to an embodiment of this application. The method includes:
[0304] S501. If the timeout timer detects a timeout in the service processing, the ADSP will be triggered to call the interrupt callback function.
[0305] S502, restart ADSP using the interrupt callback function.
[0306] S503, Generate a dump file.
[0307] S504 and ADSP send the dump file to AP.
[0308] Optionally, to ensure that the ADSP can be safely restored to normal after restarting, log entries are recorded at the beginning of the interrupt callback function call, such as when a timeout occurs and a cleanup and restart process will be executed; the current state of the ADSP can also be saved, hardware interfaces can be shut down, resources can be released, and running business processing tasks can be terminated, etc.
[0309] Optionally, upon restarting the ADSP, the subsystem on the ADSP side generates a dump file, which may contain the ADSP's status information at the time of the timeout. The ADSP automatically sends the dump file to the AP, and the AP can analyze the root cause of the AP's data transmission and reception timeout based on the information recorded in the dump file.
[0310] Alternatively, in one possible implementation, when the ADSP is restarted using the interrupt callback function, a Subsystem Restart (SSR) process is triggered, which in turn triggers the ADSP to generate an SSR dump file, and the ADSP sends the SSR dump file to the AP.
[0311] In this implementation, an ADSP restart will trigger the SSR process, which will automatically save the SSR dump file to the AP. That is, an ADSP restart will trigger the generation of an SSR dump file and automatically send the SSR dump file to the AP, which is convenient for analyzing the root cause of AP data transmission and reception timeouts.
[0312] For ease of understanding, this application also provides a flowchart illustrating the communication method executed from the ADSP side. Please refer to Figure 10, which is a flowchart illustrating an ADSP communication method provided in this application embodiment. The method includes:
[0313] S601, ADSP receives service data sent by the application processor (AP).
[0314] S602: If the receive queue in the ADSP is not full, store the service data into the receive queue and add an enqueue time to the service data.
[0315] S603. Process business data and record the start processing time corresponding to the business data.
[0316] S604. When the business data is processed, record the end processing time corresponding to the business data.
[0317] S605. If processing business data times out, the timeout information will be sent to the AP. The timeout information includes the enqueue time, start processing time, and end processing time. The timeout information is used by the AP to determine the reason for the timeout.
[0318] Specifically, the timeout information is used by the AP to determine a first time difference and / or a second time difference, and to determine the timeout reason based on the first time difference and / or the second time difference; the first time difference is determined based on the end processing time and the enqueue time, and the second time difference is determined based on the end processing time and the start processing time.
[0319] If the timeout reason is determined based on the first time difference, the timeout reason is that the number of service data received by the ADSP exceeds the preset number of received data; if the timeout reason is determined based on the second time difference, the timeout reason is that the ADSP times out processing a single service data; if the timeout reason is determined based on both the first and second time differences, the timeout reason is that the number of service data received by the ADSP exceeds the preset number of received data, and the ADSP times out processing a single service data.
[0320] In related technologies, after the AP fails to send service data, it will repeatedly send the same service data to the ADSP, causing the amount of service data to be processed in the ADSP's receive queue to increase, and even causing the ADSP's receive queue to overflow, blocking the entire communication. The communication method provided in this application allows for accurate identification of the root cause of AP data transmission and reception timeouts, which helps developers to address timeout faults in a targeted manner. For example, if the identified timeout cause includes the ADSP receiving more service data than the preset receive limit, the AP can be controlled to stop sending service data frequently, thereby effectively preventing excessive service data from blocking the ADSP, reducing the ADSP's workload, and resolving the AP data transmission and reception timeout problem. If the identified timeout cause includes a single service data timeout by the ADSP, then patiently wait for the ADSP's response.
[0321] This application embodiment also provides a flowchart illustrating the communication method executed from the AP side. Please refer to Figure 11. Figure 11 is a flowchart illustrating an AP execution communication method provided in this application embodiment. The method includes:
[0322] S701 and AP add identification information to business data.
[0323] S702, Encapsulate and add identification information to business data.
[0324] S703 sends the encapsulated service data to ADSP.
[0325] S704: Receive timeout information sent by ADSP. The timeout information includes the enqueue time, start processing time, and end processing time corresponding to the service data.
[0326] S705. Determine the reason for the timeout based on the timeout information.
[0327] It is worth noting that the AP and ADSP communicate via PMIC GLink. If the AP times out sending or receiving data, the corresponding kernel log of the AP can be obtained. If the kernel log shows that the AP has not received any response data sent by the ADSP within a preset time, the timeout reason is determined to be channel blockage between the AP and the ADSP.
[0328] If the kernel log records that the AP also received response data for other services sent by the ADSP within a preset time, it proves that the communication channel between the AP and the ADSP is not blocked, and the timeout is due to another reason.
[0329] Among them, AP data transmission and reception timeout can include AP response data receiving timeout and AP service data sending timeout. AP response data receiving timeout refers to the timeout of waiting to receive response data from ADSP; AP service data sending timeout refers to the inability to continue or complete the sending of service data within the predetermined time due to the timeout of waiting to receive response data from ADSP.
[0330] This application embodiment also provides a flowchart illustrating the execution of a communication method from the AP side and the ADSP side respectively. Please refer to Figure 12. Figure 12 is a flowchart illustrating another method for executing a communication method provided in this application embodiment. The method includes:
[0331] S801 and AP add identification information to business data.
[0332] S802, AP encapsulates and adds identification information to the service data.
[0333] S803 and AP send the encapsulated service data to ADSP.
[0334] S804, ADSP receives service data sent by AP.
[0335] S805 and ADSP detect whether there is identical business data based on the identification information.
[0336] S806 and ADSP detected the existence of identical service data and discarded the service data.
[0337] The S807 and ADSP detected that no identical service data existed and checked whether the receive queue was not full.
[0338] When the S808 and ADSP detect that the receive queue is not full, they store the service data into the receive queue and add an enqueue time to the service data.
[0339] S809 and ADSP detect that the receive queue is full, store the service data in the discard queue, and add a discard time to the service data.
[0340] The S810 and ADSP detect whether the receive queue is empty.
[0341] S811. When the receive queue is detected to be non-empty, extract the service data from the receive queue.
[0342] The S812 and ADSP start the preset timeout timer.
[0343] S813, ADSP starts processing business data and records the start time of the corresponding business data.
[0344] S814 and ADSP call the business processing function to perform business processing.
[0345] S815, ADSP disable timeout timer.
[0346] S816, ADSP records the end processing time corresponding to the business data.
[0347] S817, ADSP detects whether the processing of business data has timed out.
[0348] S818. If a timeout is detected in processing business data, the timeout information will be sent to the AP.
[0349] S819, AP determines the timeout reason based on the timeout information.
[0350] The communication method provided in this application embodiment enables the AP to accurately locate the cause of the timeout, which is beneficial for targeted solutions to the timeout problem.
[0351] It is worth noting that in the embodiment corresponding to Figure 12, during the service processing flow, if the timeout timer detects a service processing timeout, it triggers the ADSP to call the interrupt callback function, which in turn triggers the SSR process. The ADSP automatically generates an SSR dump file, and then sends the SSR dump file to the AP. In this implementation, an ADSP restart will trigger the SSR process and automatically save the SSR dump file to the AP, facilitating the analysis of the root cause of AP data transmission and reception timeouts.
[0352] Optionally, in one possible implementation, the communication method provided in this application can be applied to any scenario that requires communication using PMIC Glink. That is, as long as PMIC Glink is used to send and receive data, the communication method provided in this application can be used to add enqueue time, discard time, start processing time and end processing time to the data, so as to accurately locate the root cause of the timeout based on these time information, and thus solve the timeout problem in a targeted manner.
[0353] Optionally, based on this, the method of adding identification information to the transmitted data provided in this application can also be used to filter out duplicate data, thereby effectively avoiding the storage of a large amount of duplicate service data in the ADSP's receive queue, preventing the ADSP's receive queue from overflowing, and reducing the risk of the ADSP being blocked due to repeated reception of the same service data.
[0354] Optionally, based on this, the method provided in this application, which adds a timeout timer during the business processing, can be used to monitor whether the business processing times out and trigger a subsystem restart if a timeout occurs, thereby restoring the process of processing business data.
[0355] For example, scenarios that require PMIC Glink communication may include: UCSI GLink service scenario, Charger ULog GLink service scenario, Register Client service scenario via PMIC GLink, QTI Battery service scenario, OEM GLink service scenario, ADSP Log GLink service scenario, etc. This is only an example and is not intended to limit the scope.
[0356] The foregoing has detailed examples of the communication 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 in 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.
[0357] The embodiments of this application can divide the electronic device into functional modules according to the above method examples. For example, each function can be divided into a functional module, such as a receiving module, a processing module, a recording module, a sending module, etc., or two or more functions can be integrated into one module.
[0358] The integrated modules described above can be implemented in hardware or as software functional modules. It should be noted that the module division in this embodiment is illustrative and represents only one logical functional division; in actual implementation, other division methods may be used.
[0359] 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.
[0360] The electronic device provided in this embodiment may include an ADSP and an AP. The ADSP and AP are used to execute the aforementioned communication method, thus achieving the same effect as the aforementioned implementation method.
[0361] 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.
[0362] 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 of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (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 WiFi chip, or other devices that interact with other electronic devices.
[0363] 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 the structure shown in FIG2.
[0364] This application also provides a computer-readable storage medium storing a computer program that, when executed on an electronic device, causes the electronic device to perform the communication method of any of the above embodiments.
[0365] 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 method described in the above embodiments.
[0366] This application also provides a chip. Please refer to Figure 13, which is a schematic diagram of the structure of a chip provided in this application embodiment. The chip shown in Figure 13 can be a general-purpose processor or a dedicated processor. The chip includes a processor 910. The processor 910 is used to execute the communication method of any of the above embodiments.
[0367] Optionally, the chip also includes a transceiver 920, which is used to receive control from the processor and to support the communication device in executing the aforementioned technical solution.
[0368] Optionally, the chip shown in Figure 13 may also include a storage medium 930.
[0369] It should be noted that the chip shown in Figure 13 can be implemented using the following circuits or devices: one or more field programmable gate arrays (FPGAs), programmable logic devices (PLDs), controllers, state machines, gate logic, discrete hardware components, any other suitable circuits, or any combination of circuits capable of performing the various functions described throughout this application.
[0370] 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.
[0371] 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.
[0372] 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 device, 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 devices or units may be electrical, mechanical, or other forms.
[0373] 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.
[0374] 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.
[0375] 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.
[0376] 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 within the scope of the claims.
Claims
1. A communication method, characterized in that, The method, applied to an application digital signal processor (ADSP), includes: the ADSP receiving service data sent by an application processor (AP); detecting that the receive queue in the ADSP is not full, storing the service data in the receive queue and adding an enqueue time to the service data; processing the service data and recording the start processing time corresponding to the service data; recording the end processing time corresponding to the service data when the processing of the service data is completed; if the processing of the service data times out, sending timeout information to the AP, the timeout information including the enqueue time, the start processing time, and the end processing time; the timeout information is used by the AP to determine a first time difference and / or a second time difference, and according to the first time difference... The timeout reason is determined by the time difference and / or the second time difference; the first time difference is determined based on the end processing time and the enqueue time, and the second time difference is determined based on the end processing time and the start processing time; if the timeout reason is determined based on the first time difference, the timeout reason is that the number of service data received by the ADSP exceeds the preset number of received data; if the timeout reason is determined based on the second time difference, the timeout reason is that the ADSP times out processing a single piece of service data; if the timeout reason is determined based on both the first time difference and the second time difference, the timeout reason is that the number of service data received by the ADSP exceeds the preset number of received data, and the ADSP times out processing a single piece of service data.
2. The method according to claim 1, characterized in that, The AP and the ADSP communicate via the GLink inter-core communication link of the power management integrated circuit (PMIC).
3. The method according to claim 1, characterized in that, The service data sent by the AP includes identification information. Before detecting that the receive queue in the ADSP is not full, storing the service data in the receive queue, and adding an enqueue time to the service data, the method further includes: determining whether there is identical service data corresponding to the service data in the receive queue based on the identification information; if there is no identical service data in the receive queue, detecting whether the receive queue in the ADSP is not full.
4. The method according to claim 3, characterized in that, After determining whether there is identical business data corresponding to the business data in the receiving queue based on the identification information, the method further includes: if there is identical business data corresponding to the business data in the receiving queue, then discarding the business data.
5. The method according to any one of claims 1 to 3, characterized in that, The method further includes: if there is no identical service data corresponding to the service data in the receiving queue, and the receiving queue in the ADSP is full, storing the service data in a preset discard queue and adding a discard time to the service data.
6. The method according to claim 1, characterized in that, The process of processing the business data and recording the start processing time corresponding to the business data includes: extracting the business data from the receiving queue; starting a preset timeout timer; obtaining the start processing time corresponding to the business data; and calling the business processing function corresponding to the business data to perform business processing.
7. The method according to claim 6, characterized in that, The method further includes: if the timeout timer detects a service processing timeout, triggering the ADSP to call an interrupt callback function; and restarting the ADSP using the interrupt callback function.
8. The method according to claim 7, characterized in that, The method further includes: generating a dump file; sending the dump file to the AP, wherein the dump file is used by the AP to determine the timeout reason, wherein the timeout reason is that the ADSP has failed.
9. The method according to claim 6, characterized in that, The method further includes: if the timeout timer detects that the service processing has not timed out, recording the end processing time corresponding to the service data.
10. A communication method, characterized in that, The method, applied to an application processor (AP), includes: the AP adding identification information to service data; encapsulating the service data with added identification information; sending the encapsulated service data to an application digital signal processor (ADSP); receiving timeout information sent by the ADSP, the timeout information including the enqueue time, start processing time, and end processing time corresponding to the service data; determining a first time difference and / or a second time difference based on the timeout information, and determining a timeout cause based on the first time difference and / or the second time difference; the first time difference being determined based on the end processing time and the enqueue time, and the second time difference being determined based on the end processing time and the start processing time; if the timeout cause is determined based on the first time difference, the timeout cause is that the number of service data received by the ADSP exceeds a preset number of received data; if the timeout cause is determined based on the second time difference, the timeout cause is that the ADSP times out processing a single piece of service data; if the timeout cause is determined based on both the first and second time differences, the timeout cause is that the number of service data received by the ADSP exceeds the preset number of received data, and the ADSP times out processing a single piece of service data.
11. The method according to claim 10, characterized in that, The method further includes: obtaining the kernel log corresponding to the AP; if it is detected that the AP has not received any response data sent by the ADSP within a preset time period, the timeout reason is determined to include channel blockage between the AP and the ADSP.
12. The method according to claim 11, characterized in that, The AP and the ADSP communicate via the GLink inter-core communication link of the power management integrated circuit (PMIC).
13. An electronic device, characterized in that, The electronic device includes an application digital signal processor (ADSP) and an application processor (AP), wherein the ADSP performs the method as described in any one of claims 1 to 9, and the AP performs the method as described in any one of claims 10 to 12.
14. 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 claimed in any one of claims 1 to 9, and to perform the method as claimed in any one of claims 10 to 12.
Citation Information
Patent Citations
Enqueue-related processing based on timing out of an attempted enqueue
US10585730B1