A configuration method, storage medium and electronic device

Abstract

The application relates to the technical field of software, and discloses a configuration method, a storage medium and an electronic device. In the configuration method, a first electronic device such as a mobile phone comprises a first controller such as a DCC controller. The configuration parameter file of the DCC controller is set in a second electronic device, so that the first electronic device can directly download and configure the configuration parameter file from the second electronic device. After a first fault occurs, the first controller can acquire relevant information of the first fault according to the configured configuration parameter file, data support is provided for a technician to find problems of a hardware module, and the efficiency of the technician to determine the cause of the problem of the hardware module is improved.

Description

Technical Field

[0001] This invention relates to the field of software technology, and more particularly to a configuration method, storage medium, and electronic device. Background Technology

[0002] When a hardware module inside an electronic device malfunctions, the cause of the problem can usually be determined by the status information of the hardware module's registers captured by the internal data capture and compare engine (DCC) (DCC controller).

[0003] For example, technicians can analyze memory dump files (DUMP files) to initially identify the problematic hardware module. Then, based on the internal structure of these hardware modules—such as their components—they can obtain the register configuration values ​​(including register addresses and instructions for capturing or not capturing status information) of each component from the hardware module's chip design manual. Technicians can then submit the register configuration values ​​of the initially identified problematic hardware module's components to the code repository for recompilation. These register configuration values ​​will be combined with other modifications to form a new software system version, which will then be pushed to users. A DUMP file is a binary file generated by the operating system or application when a computer system encounters abnormal situations such as system crashes, application crashes, or abnormal termination. It records critical data such as the system's memory state and register values ​​at the time of the error.

[0004] When a user upgrades the software system of an electronic device with a new software version, the register configuration values ​​provided by the technician are written to the DCC controller. If the hardware module malfunctions again, the electronic device's central processing unit (CPU) can activate the DCC controller, which will automatically retrieve the status information of the corresponding component's registers based on the register configuration values. Technicians can use the retrieved register status information to determine the cause of the hardware module problem, such as a faulty component within the hardware module.

[0005] On the one hand, since the process of submitting register configuration values ​​to the code repository and generating a new software system version to push to the customer can take several days, relying on generating a new software system version to write the register configuration values ​​into the DCC controller and make them effective in the DCC controller will ultimately affect the efficiency of determining the cause of the hardware module problem. On the other hand, since the new software system version may include modification information that affects the recurrence of other problems with the current hardware module, the problem may not be reproduced or may have a low probability of reproduction in the new software system version. Therefore, relying on generating a new software system version to write the register configuration values ​​into the DCC controller will also delay the progress of determining the cause of the hardware module problem. Summary of the Invention

[0006] This invention provides a configuration method, storage medium, and electronic device, which improves the efficiency of technicians in determining the cause of hardware module problems.

[0007] In a first aspect, the present invention provides a configuration method applied to an electronic device, comprising: obtaining a configuration parameter file of a first controller from a second electronic device, the configuration parameter file including an instruction for obtaining fault-related parameters of a first hardware module in the first electronic device and a storage address of the fault-related parameters; configuring the configuration parameter file into the first controller; detecting a first fault in the first electronic device, and controlling the first controller to obtain fault-related parameters from the storage address of the fault-related parameters based on the instruction for obtaining fault-related parameters in the configuration parameter file.

[0008] In this context, the first electronic device corresponds to the electronic device mentioned below, such as a mobile phone; the second electronic device corresponds to the cloud-side electronic device or cloud-side server mentioned below; the first hardware module corresponds to the hardware module that may have problems mentioned below; the configuration parameter file corresponds to the DCC configuration parameter file mentioned below; the first controller corresponds to the DCC controller mentioned below; and the first fault corresponds to the system fault mentioned below.

[0009] The above configuration method can improve the efficiency of the first electronic device in obtaining the configuration parameter file of the first controller by obtaining the configuration parameter file in real time from the second electronic device. Furthermore, when the first electronic device experiences a first fault, it can immediately obtain fault-related parameters based on the configuration parameter file, thereby further improving the efficiency of determining the cause of the hardware module problem.

[0010] In one possible implementation of the first aspect, the fault-related parameters include the status information of the registers of the first hardware module.

[0011] In the above configuration method, a configuration parameter file can be composed of the storage address of fault-related parameters, including the status information of the registers of the first hardware module, and the instructions for obtaining these fault-related parameters. Therefore, when the first electronic device experiences a first fault, it can immediately retrieve the status information of the registers of the first hardware module, thereby improving the efficiency of determining the cause of the hardware module problem.

[0012] In one possible implementation of the first aspect, obtaining the configuration parameter file of the first controller from the second electronic device includes: receiving a first download instruction and a first configuration instruction sent by the second electronic device, wherein the first download instruction instructs the first electronic device to download the configuration parameter file, and the first configuration instruction instructs the first electronic device to configure the configuration parameter file into the first controller; and downloading the configuration parameter file of the first controller from the second electronic device, corresponding to receiving a first authorization instruction from a user's first fault log. The first fault log corresponds to the fault log mentioned below.

[0013] The first download instruction can correspond to the open state of file switch 312 in the following text; the first configuration instruction can correspond to the open state of DCC configuration switch 311 in the following text; the first fault log corresponds to the fault log in the following text; the user's first authorization instruction for the first fault log can correspond to the user's authorization instruction to select to start the fault log collection process and select to provide feedback on the fault log in the following text.

[0014] It is understood that the first electronic device can obtain the configuration parameter file of the first controller from the second electronic device when it receives the first download command and the first configuration command sent by the second electronic device, as well as the first authorization command of the first fault log from the user. Through bidirectional commands from the user and the second electronic device, the security of the first electronic device obtaining the configuration parameter file of the first controller from the second electronic device is ensured.

[0015] In one possible implementation of the first aspect, the first download instruction includes a storage path for the configuration parameter file and a key, and downloads the configuration parameter file of the first controller from the second electronic device, including: downloading the configuration parameter file of the first controller from the storage path of the second electronic device based on the key.

[0016] It is understandable that the first download instruction sent by the second electronic device may include the storage path and key of the configuration parameter file to be downloaded. Therefore, after the first electronic device receives the first download instruction, it can obtain the download address of the configuration parameter file by parsing the content of the first download instruction.

[0017] In one possible implementation of the first aspect, configuring the configuration parameter file into the first controller includes: in response to a first configuration instruction, determining that the configuration parameter file meets configuration conditions, wherein the configuration conditions include the version number of the configuration parameter file being a first version number, and the configuration parameter file corresponding to the model of the first electronic device; and executing a script of the configuration parameter file to configure the configuration parameter file into the first controller.

[0018] It is understandable that the process of the first electronic device configuring the configuration parameter file into the first controller requires confirmation of whether the configuration parameter file meets the configuration conditions after receiving the first configuration command sent by the second electronic device. For example, the first electronic device needs to confirm that the version number of the configuration parameter file is the first version number, which can be the correct version number mentioned below, i.e., the version number required for the current configuration. Furthermore, it also needs to determine that the configuration parameter file corresponds to the signal of the current first device, such as corresponding to the mobile phone model mentioned below.

[0019] In one possible implementation of the first aspect, executing a script for a configuration parameter file to configure the configuration parameter file into the first controller includes: shutting down the engine of the first controller; deleting the first configuration parameter file of the first controller; storing the contents of the configuration parameter file into the corresponding memory; setting the operating mode of the first controller; and starting the engine of the first controller.

[0020] It can be understood that the first configuration parameter file corresponds to the configuration parameters in the DCC controller that need to be cleared in step S720 below, that is, the configuration parameters that have been configured in the DCC controller before this configuration process. The operating mode of the first controller corresponds to the capture mode below, that is, the DCC controller can capture the necessary information when the first electronic device fails again, that is, when the system fails.

[0021] In one possible implementation of the first aspect, executing a script of the configuration parameter file to configure the configuration parameter file into the first controller further includes setting the memory address where the first fault log is stored.

[0022] It is understandable that the first fault log will be stored in a pre-set memory address, and the first electronic device can feed back the first fault log to the first electronic device to provide data for determining the cause of the hardware module problem.

[0023] In one possible implementation of the first aspect, a first fault is detected in the first electronic device, and the first controller is controlled to obtain fault-related parameters from the storage address of the fault-related parameters based on the acquisition instruction of the fault-related parameters in the configuration parameter file, including: detecting a first fault in the first electronic device; controlling the first controller to perform detection based on the configuration parameter file, and obtaining a first fault log of the fault-related parameters.

[0024] It is understandable that the first controller can perform detection based on the configured parameter file when the first electronic device experiences a first fault, thereby improving the efficiency of obtaining the first fault log.

[0025] Secondly, this document provides a time-consuming detection device, including one or more processors and one or more memories; the one or more memories are coupled to one or more processors, and the one or more memories are used to store computer program code, the computer program code including computer instructions, which, when the one or more processors execute the computer instructions, cause the device to perform any of the configuration methods provided by the first aspect above and various possible implementations of the first aspect above.

[0026] Thirdly, this article provides a chip including a processor that executes computer instructions stored in a computer storage medium, causing an electronic device to implement any of the configuration methods provided by the various possible implementations of the first aspect above.

[0027] Fourthly, this document provides a readable storage medium storing instructions that, when executed on an electronic device, cause the electronic device to implement any of the configuration methods provided by various possible implementations of the first aspect above.

[0028] Fifthly, this document provides an electronic device comprising: a memory for storing instructions executable by one or more processors of the electronic device; and a processor, one of the processors of the electronic device, for executing the instructions stored in the memory to implement any of the configuration methods provided by various possible implementations of the first aspect above.

[0029] Sixthly, this document provides a program product including instructions that, when executed by an electronic device, enable the electronic device to implement any of the configuration methods provided by the various possible implementations of the first aspect above. Attached Figure Description

[0030] Figure 1 According to some embodiments of the present invention, a schematic diagram of a process in which register configuration values ​​are written to a DCC controller is shown;

[0031] Figure 2 According to some embodiments of the present invention, a schematic diagram of a configuration method in a usage scenario is shown;

[0032] Figure 3 According to some embodiments of the present invention, a schematic diagram of a software module for a configuration method is shown;

[0033] Figure 4According to some embodiments of the present invention, a flowchart of a configuration method is shown;

[0034] Figure 5 According to some embodiments of the present invention, a schematic diagram of the process for the activation of DCC configuration information is shown;

[0035] Figure 6 According to some embodiments of the present invention, a flowchart illustrating the process of parsing and configuring a DCC configuration parameter file is shown;

[0036] Figure 7 According to some embodiments of the present invention, a schematic diagram of a process for configuring a DCC configuration parameter file is shown;

[0037] Figure 8 According to some embodiments of the present invention, a schematic diagram of a DCC controller capturing register states is shown;

[0038] Figure 9 According to some embodiments of the present invention, a schematic diagram of the hardware structure of an electronic device is shown. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0040] As described in the background section, when a problem occurs in a hardware module within an electronic device, technicians, based on preliminary analysis, obtain the register configuration values ​​of various components within the potentially problematic hardware module from the hardware module chip design manual. These register configuration values ​​are then submitted to the code repository for recompilation, generating a new software system version which is subsequently pushed to the user. When the user upgrades the electronic device's software system according to the new version, these register configuration values ​​are written to the DCC controller. This writing process typically includes... Figure 1 The two methods shown.

[0041] like Figure 1 As shown, after obtaining a new software system version, the user can update the software system of the electronic device. After restarting the electronic device, the new software system initializes, and the kernel initialization process of the electronic device starts.

[0042] After the kernel initialization process starts, i.e., after step S110, the register configuration values ​​can be written to the DCC controller using the first method in step S120. Specifically, the first method includes: initializing the DCC controller driver and loading the DCC configuration information from the dtsi file. This allows the register configuration values ​​provided by the technician to be written to the DCC controller. The DCC configuration information may include the register configuration values ​​of various components in the potentially problematic hardware modules of the aforementioned electronic device, provided by the technician. For example, the register configuration values ​​could be...<register address=“Ox1740003c”value=“0x00000010”> Among them, "0x1740003c" and "0x00000010" are instructions for capturing status information.

[0043] As you can understand, .dtsi is the header file for the device tree, with the extension .dtsi. The .dtsi can contain information about any hardware module in the electronic device, such as clock or Bluetooth configuration information. The device tree is a data structure that describes the hardware module information on the electronic device; it is passed to the kernel by the bootloader.

[0044] Alternatively, after the kernel initialization process of the electronic device starts, i.e., after step S110, the register configuration values ​​can be written to the DCC controller using the second method in step S130. The second method includes resetting the DCC configuration information through the rc script of the kernel initialization process and enabling the DCC configuration information within the rc script. The rc script can include the register configuration values ​​of various components in the potentially problematic hardware modules of the aforementioned electronic device, provided by technical personnel. The rc script is used to initialize system services, set attributes, create system resources, and perform other operations. The rc script completes scanning, parsing, loading, and execution operations within the kernel initialization process.

[0045] It's understandable that both methods of writing register configuration values ​​to the DCC controller require generating a new software system version before implementation. However, generating a new software system version involves committing the register configuration values ​​to the code repository and then compiling, a process that is time-consuming. Furthermore, the new software system version may include other modifications, such as adding new functionality to the hardware module to fix current hardware module issues, or making the current hardware module's problems disappear in certain scenarios. This means that after the user updates the software system version, the current hardware module's problems will not reproduce or will reproduce with a low probability in the new software system version. Therefore, relying on generating a new software system version to write register configuration values ​​to the DCC controller will affect the efficiency of determining the cause of the hardware module problem and delay the progress of determining the cause of the hardware module problem.

[0046] In view of this, this application discloses a configuration method in which the electronic device can automatically download a DCC configuration parameter file pre-stored on the cloud side based on instructions received from a technician on the cloud side to configure the DCC controller, and based on user authorization to collect and feedback fault logs, and complete the configuration of the DCC controller to update the configuration information in the DCC controller in real time. The DCC configuration parameter file includes register configuration values ​​for each component in the hardware module from which register status information needs to be captured, provided by the technician based on a previous DUMP file.

[0047] The above configuration method allows the DCC controller of the electronic device to obtain the DCC configuration parameter file in real time, without having to combine the DCC configuration parameter file with other modification information to generate a new software system version, and then push the new software system version to the user for software system updates. This method writes the contents of the DCC configuration parameter file into the DCC controller. Furthermore, this configuration method does not involve modifications that affect the current hardware module, and does not prevent the recurrence of the current hardware module problem. This allows the DCC controller to capture the necessary hardware module register status information based on the real-time updated configuration information during the next system failure, providing data support for technicians to analyze and determine the cause of the hardware module problem. This significantly improves the efficiency of the DCC controller in obtaining configuration information, thereby greatly improving the efficiency of technicians in determining the cause of hardware module problems, and does not delay the process of determining the cause of hardware module problems.

[0048] It is understood that the electronic devices in the embodiments of this application can be smartphones (e.g., phones running Android or iOS systems), tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices (e.g., smartwatches, smart bracelets), or other electronic devices. In the following embodiments of this application, a mobile phone will be used as an example for illustration. The cloud side in this application can be understood as cloud-side electronic devices, cloud-side servers, etc.

[0049] The following is in conjunction with the appendix Figure 2 To be continued Figure 9 The technical solution disclosed in this application will be introduced.

[0050] Figure 2 A diagram illustrating a use case for one configuration method is shown. For example... Figure 2 As shown, technicians can provide the register configuration values ​​of each component in the potentially problematic hardware module and store the DCC configuration parameter file, including these register configuration values, on a cloud-side server. Then, technicians can send instructions to the mobile phone to configure the DCC controller through the cloud-side human-machine interface. Users can authorize the collection and feedback of fault logs through the mobile phone's human-machine interface. After receiving the DCC controller configuration instructions from the cloud and the authorization information entered by the user, the mobile phone will download the DCC configuration parameter file from the cloud. Finally, the mobile phone can configure the DCC controller according to the DCC configuration parameter file, thereby configuring the register configuration values ​​of each component in the potentially problematic hardware module provided by the technician into the DCC controller.

[0051] Figure 3 A schematic diagram of a software module for a configuration method is shown.

[0052] like Figure 3 As shown, the cloud-side software modules may include: a dynamic switch configuration management module 310, a remote server module 320, a two-way channel module 330, and a cloud configuration server module 340.

[0053] The dynamic switch configuration management module 310 may include two dynamic switches: a DCC configuration switch 311 and a file switch 312. The module stores the dynamic switches and includes a human-machine interface. For example, technicians can use the module to select, modify, add, delete, and change the attribute information of dynamic switches. The attribute information of the dynamic switches may be either file-based or command-based; for example, a file-based switch is used to download files, while a command-based switch is used to start tasks. The DCC configuration switch 311 is a command-based switch used to initiate the DCC controller configuration task. The file switch 312 is a file-based switch used to initiate the task of downloading the DCC configuration parameter file.

[0054] The dynamic switch configuration management module 310 can send the on / off status of the DCC configuration switch 311 and the file switch 312 to the dynamic switch configuration module 321 in the remote server module 320, and can also display the switch status stored in the dynamic switch configuration module 321 on the human-machine interface. The dynamic switch configuration management module 310 can also push information to the mobile phone side through the bidirectional channel module 330.

[0055] It is understandable that the dynamic switch configuration management module 310 could be Ares Ocean. Ares Ocean is an open-source dynamic configuration center, a dynamic configuration system developed based on the Java language. It can be used to centrally and dynamically manage the configuration in applications, and also allows applications to quickly change runtime application configurations through a combination of monitoring and pulling.

[0056] The remote server module 320 may include a dynamic switch configuration module 311 and a remote log collection module 322. The dynamic switch configuration module 311 stores the status of the dynamic switches issued by the dynamic switch configuration management module 310. The remote log collection module 322 sends instructions to the mobile phone side to collect fault logs and receives the collected fault logs uploaded by the mobile phone side.

[0057] The bidirectional channel module 330 is used to push the dynamic switch information sent by the dynamic switch configuration management module 310 to the dynamic switch service module 360 ​​on the mobile phone side. For example, the dynamic switch information may include information about the DCC configuration switch 311, such as the open or closed status of the DCC configuration switch 311; and information about the file switch 312, such as the open or closed status of the file switch 312 and the corresponding file information, including the storage path and key of the DCC configuration parameter file.

[0058] The cloud configuration server module 340 stores the corresponding file information of the dynamic switch and provides an interface for the mobile phone to download the configuration parameter file of the dynamic switch. The cloud configuration server module 340 may include a DCC configuration parameter file module 341. The DCC configuration parameter file module 341 stores the DCC configuration parameter file and key corresponding to the file switch 312. The DCC configuration parameter file includes the configuration parameters of the DCC controller, that is, the register configuration values ​​of each component in each hardware module of the mobile phone provided by the technicians.

[0059] It is understandable that the cloud configuration server module 340 can be the WiseOper platform, which is used to store and manage file uploads and downloads.

[0060] The mobile phone-side software modules may include an intelligent detection module 350, a dynamic switch service module 360, and a terminal-side parsing service module 370. The intelligent detection module 350 and the dynamic switch service module 360 ​​can be integrated into a single application (APP), or they can belong to different APPs or a shared APP. In this embodiment, the type and number of APPs mentioned in the mobile phone-side software modules are not specifically limited.

[0061] The intelligent detection module 350 may include a self-feedback log module 351, a remote log collection module 352, and a dynamic privacy authorization module 353. The intelligent detection module 350 is used to initiate the relevant processes for remote log collection, initiate the relevant processes for self-feedback log collection, initiate the task of displaying a privacy control pop-up, and upload fault logs to the remote log collection module 322 on the cloud side.

[0062] The self-feedback log module 351 initiates the self-feedback log collection process and sends a first query instruction to the dynamic privacy authorization module 353, which instructs the user to choose whether to report fault logs. The remote log collection module 352 receives the instruction to collect fault logs from the remote log collection module 322 on the cloud and then sends a second query instruction to the dynamic privacy authorization module 353, which instructs the user to choose whether to start the fault log collection process. The dynamic privacy authorization module 353 displays a privacy control pop-up, in which the user can choose whether to start the fault log collection process and whether to report fault logs. The dynamic privacy authorization module 353 also sends the user's selection to the log switch module 362 and, after collecting fault logs, uploads them to the remote log collection module 322 on the cloud.

[0063] It is understood that the dynamic privacy authorization module 353 may only display a pop-up for the user to choose after the phone starts up, or it may display a pop-up for the user to choose in other scenarios where it is needed. In this embodiment of the application, there is no specific limitation on the number of times and scenarios in which the dynamic privacy authorization module 353 displays a pop-up.

[0064] The dynamic switch service module 360 ​​includes a switch status update module 361, a switch log module 362, a switch parameter parsing module 363, a judgment module 364, a configuration parameter download module 365, an integrity verification module 366, and a switch activation module 367.

[0065] It is understandable that the Dynamic Switch Service Module 360 ​​can be used for Hiview applications. The Dynamic Switch Service Module 360 ​​can be used to receive user-authorized information for fault log collection, as well as dynamic switch information issued by the cloud platform; it can be used to download configuration parameter files for dynamic switches from the cloud platform, such as DCC configuration parameter files, and to verify these files; it can also trigger the parsing service module 370 to parse and configure the downloaded dynamic switch configuration parameter files, such as parsing the downloaded DCC configuration parameter files and configuring them into the DCC controller; and it can also be used to delete the dynamic switch's configuration parameters, such as deleting the DCC configuration parameter file, after receiving the dynamic switch's off status from the cloud platform.

[0066] The update switch status module 361 is used to receive dynamic switch information sent by the bidirectional channel module 330 on the cloud side, and send the dynamic switch information to the log switch module 362.

[0067] The log switch module 362 is used to determine whether to send the task of starting the dynamic switch and the information of the dynamic switch to the judgment module 364 based on the dynamic switch status information sent by the update switch status module 361 and the user selection information (i.e. whether to agree to start the fault log collection process and whether to agree to report the fault log) sent by the dynamic privacy authorization module 353.

[0068] For example, if the update switch status module 361 sends the state of DCC configuration switch 311 as open, the state of file switch 312 as open, and the dynamic privacy authorization module 353 sends the user's selection information as agreeing to collect fault logs and agreeing to report fault logs, then the log switch module 362 will start the task of the dynamic switch in the open state, such as starting the task of DCC controller configuration, starting the task of downloading DCC configuration parameter files, and the storage path and key of DCC configuration parameter files, and send them to the judgment module 364.

[0069] If the DCC configuration switch 311 sent by the update switch status module 361 is in the off state, the file switch 312 is in the off state, and the user selection information sent by the dynamic privacy authorization module 353 is to agree to collect fault logs and agree to provide feedback on fault logs, then the log switch module 362 will not perform any operation.

[0070] If the DCC configuration switch 311 sent by the update switch status module 361 is in an open or closed state, the file switch 312 is in an open or closed state, and the user selection information sent by the dynamic privacy authorization module 353 is "disagree to collect fault logs" and "disagree to report fault logs", then the log switch module 362 will not perform any operation.

[0071] It is understood that the operations performed by the log switch module 362 will be determined based on the dynamic switch information sent from the cloud side and the user selection information sent by the intelligent detection module 350. The log switch module 362 can also clear the directory information and related content of dynamic switches previously stored in the mobile phone, such as the directory information and related content of dynamic switches stored in the mobile phone's secure digital card (SDC).

[0072] The judgment module 364 is used to determine whether the dynamic switch to be activated is a file type based on the content sent by the log switch module 362. If the dynamic switch to be activated is determined to be a file type, for example, if the judgment module 364 determines that the dynamic switch to be activated is file switch 312, then the judgment module 364 will initiate the task of downloading the DCC configuration parameter file, as well as the storage path and key of the DCC configuration parameter file, and send it to the switch parameter parsing module 363.

[0073] The parsing switch parameter module 363 is used to parse information from the file switch 312, such as the storage path and key of the DCC configuration parameter file, and to query the DCC configuration parameter file module 341 in the cloud configuration server module 340 to see if a corresponding DCC configuration parameter file is stored. If a corresponding DCC configuration parameter file is found in the DCC configuration parameter file module 341, the configuration parameter download module 365 can download the found DCC configuration parameter file, store it in the corresponding directory on the secure digital card, and send the DCC configuration parameter file to the integrity verification module 366 for verification.

[0074] The integrity verification module 366 can use relevant algorithms stored internally, such as the SHA265 algorithm, to verify the DCC configuration parameter file and send the verified DCC configuration parameter file to the execution switch activation module 367. For example, the integrity verification module 366 can verify whether the DCC configuration parameter file has been downloaded completely, and decrypt the DCC configuration parameter file, etc.

[0075] If the dynamic switch to be activated is not a file type, for example, if the determination module 364 determines that the dynamic switch to be activated is DCC configuration switch 311, then the determination module 364 will start the DCC controller configuration task and send it to the switch parameter parsing module 363.

[0076] The execution switch activation module 367 can send the received and verified DCC configuration parameter file, as well as the task of activating the DCC configuration switch 311, to the end-side parsing service module 370.

[0077] The endpoint parsing service module 370 is used to parse the received information and perform configuration tasks after parsing. The endpoint parsing service module 370 may include a DCC configuration service module 371. The DCC configuration service module 371 can parse the received, verified DCC configuration parameter file and configure it into the DCC controller. The specific process of the DCC configuration service module 371 parsing and configuring the received, verified DCC configuration parameter file is described below. Figure 6 and Figure 7 Detailed description.

[0078] Figure 4 Based on Figure 3 The diagram shown illustrates a configuration method for one type of software module. It can be understood that... Figure 4 The configuration method in the document is executed by the mobile phone.

[0079] In a mobile phone's system-on-chip (SoC), after detecting a system fault, such as an address access error, sleep / wake-up issue, or CPU core hangup, technicians will, based on preliminary analysis, provide the register configuration values ​​for each component in the potentially problematic hardware module. These provided register configuration values, i.e., the DCC configuration parameter file, are then stored in... Figure 3 Cloud configuration server module 341 on the cloud side. For example... Figure 4 As shown, a configuration method may include the following steps:

[0080] S410 receives authorization from the user to collect and report fault logs, as well as instructions from the cloud side to configure the DCC controller.

[0081] It is understandable that the instructions sent from the cloud side to configure the DCC controller include... Figure 2 The dynamic switch information sent by the dynamic switch configuration management module 310 includes the open status of the DCC configuration switch 311, the open status of the file switch 312, the storage path of the DCC configuration parameter file, and the key.

[0082] The S420 downloads the DCC configuration parameter file from the cloud according to the instruction information.

[0083] It is understandable that the DCC configuration parameter file can be downloaded from the DCC configuration parameter file module 341 on the cloud side, based on the storage path and key of the DCC configuration parameter file in the instruction.

[0084] S430 parses the DCC configuration parameter file according to a preset algorithm to obtain the parsed DCC configuration parameter file.

[0085] S440, configures the DCC configuration parameter file into the DCC controller.

[0086] The specific parsing process in step S430 and the specific configuration process in step S440 will be discussed in detail below. Figure 6 and Figure 7 Detailed description.

[0087] It's understandable that, on the one hand, for issues involving the coupling of multiple hardware modules within a mobile phone, technicians might provide a set of register configuration values ​​after initial troubleshooting and analysis. Then, after the problem recurs, they might conduct further troubleshooting and analysis. If the potentially problematic hardware module is found to be another module, technicians need to provide new register configuration values ​​again and push them to the user. This multiple rounds of troubleshooting and analysis makes determining the cause of the hardware module problem inefficient. On the other hand, pushing new software system updates to the DCC controller configuration might not work if the new software system version includes other modifications, such as adding new functions to the hardware module to fix the current hardware module's problem, or making the current hardware module's problem no longer occur in certain scenarios. This could lead to the current hardware module's problem not reproducing or having a low probability of recurrence in the new software system version.

[0088] Therefore, using the above configuration method, based on the instructions sent by technicians to configure the DCC controller on the cloud side, and the information authorized by the user to collect and feedback fault logs, the DCC configuration parameter file pre-stored in the cloud server can be automatically downloaded from the cloud side, and the DCC controller configuration can be completed. This updates the configuration information in the DCC controller, allowing it to capture the status information of the necessary hardware module registers based on the updated configuration information during the next system failure. This provides a reference for technicians to analyze and determine the cause of hardware module problems. By updating the DCC controller configuration in real time, the efficiency of technicians in determining the cause of hardware module problems is improved.

[0089] Figure 5 The diagram illustrates the process by which the DCC configuration information takes effect after using the above configuration method. It can be understood that the process of making the DCC configuration information effective is executed by the mobile phone.

[0090] After restarting the phone, the software system initializes, such as... Figure 5 As shown, the process for DCC configuration information to take effect may include:

[0091] S510, kernel initialization process starts.

[0092] S520, DCC controller driver initialization, and loads DCC configuration information from the dtsi file.

[0093] The S530 resets the DCC configuration information through the rc script of the kernel initialization process and enables the DCC configuration information within the rc script.

[0094] It can be understood that the process of making DCC configuration information effective may include the procedures in steps S520 and S530, or may only include the procedures in step S520, or only include the procedures in step S530. Steps S510 to S530 respectively correspond to the attached... Figure 1 Steps S110 to S130 in the embodiment of this application are not specifically limited for the DCC configuration information steps before step S540.

[0095] The S540 resets the DCC configuration information by pushing the DCC configuration information through the cloud, thus updating the DCC configuration information.

[0096] It's understandable, it can be based on Figure 4 The configuration method shown is the method for resetting the DCC configuration information in Cloud Push DCC.

[0097] During the process of the aforementioned DCC configuration information taking effect, after the mobile phone kernel initialization process starts, the DCC controller can be reconfigured and the DCC configuration information updated using the above configuration method, i.e., the method of pushing DCC configuration information from the cloud side. Then, after the mobile phone detects the next system failure, it can start the DCC controller to capture the status information of the required registers based on the updated DCC configuration information.

[0098] Figure 6 It shows Figure 3 The DCC configuration service module 371 in the text describes the specific process of parsing and configuring the DCC configuration parameter file. It can be understood that this process is executed by the mobile phone.

[0099] like Figure 6 As shown, the process of parsing and configuring the DCC configuration parameter file may include:

[0100] S610, initiate the DCC controller configuration task.

[0101] It is understood that the DCC configuration service module 371 will start parsing the DCC configuration parameter file according to the task of starting the DCC configuration switch 311 and the task of starting the file switch 312 sent by the execution switch activation module 367.

[0102] S620, confirm that the version number of the DCC configuration parameter file is correct and that the DCC configuration parameter file is compatible with the phone model.

[0103] It is understandable that after the DCC configuration service module 371 obtains the verified DCC configuration parameter file, it will also verify, according to the pre-set algorithm, whether this DCC configuration parameter file corresponds to the mobile phone model, and whether the version number of this DCC configuration parameter file is correct, such as whether it is the version number required for the current configuration.

[0104] S630, confirm that the script format of the DCC configuration parameter file is correct.

[0105] It is understood that the script format of the DCC configuration parameter file can include text format, XML format, etc. The DCC configuration service module 371 can verify whether the script format of the DCC configuration parameter file is correct based on the pre-stored script format. In the embodiments of this application, no specific limitation is made on the script format of the DCC configuration parameter file.

[0106] S640 executes the script in the DCC configuration parameter file.

[0107] It can be understood that the DCC configuration service module 371 configures the contents of the DCC configuration parameter file into the DCC controller. The specific method by which the DCC configuration service module 371 configures the contents of the DCC configuration parameter file into the DCC controller will be explained below. Figure 7 Detailed description.

[0108] like Figure 7 As shown, in step S640 above, the process by which the DCC configuration service module 371 executes the script in the DCC configuration parameter file and configures the contents of the DCC configuration parameter file into the DCC controller may include:

[0109] S710, engine with DCC controller off.

[0110] It is understandable that the DCC controller engine needs to be shut down before reconfiguring the DCC controller; otherwise, new DCC configuration parameters cannot be configured.

[0111] S720, clear the configuration parameters in the DCC controller.

[0112] S730, set the memory location that needs to be configured in the DCC controller.

[0113] It is understood that a mobile phone may include several memory blocks for the DCC controller, and the address of each memory block can be represented in the form of a linked list. Therefore, the linked list number can be used to guide the memory location that needs to be configured. In the embodiments of this application, no specific limitation is made on the memory location in the DCC controller that needs to be configured.

[0114] S740, set the DCC controller's operating mode to capture mode.

[0115] It is understandable that after setting the DCC controller's operating mode to capture mode, the DCC controller can capture the required register status information upon startup.

[0116] S750, select the memory where fault data is stored.

[0117] It is understandable that the memory can be static random-access memory (SRAM). After the DCC controller retrieves fault data based on the contents of the DCC configuration parameter file, it will store the fault data in the designated memory. The fault data may include the status information of the registers retrieved by the DCC controller.

[0118] In the embodiments of this application, the memory in which the fault data is stored is not specifically limited.

[0119] The S760 stores the contents of the DCC configuration parameter file into the corresponding memory.

[0120] S770, the engine that starts the DCC controller.

[0121] It is understandable that after configuring the DCC configuration parameters in the DCC controller, the DCC controller engine will be started. Then, the DCC controller will retrieve the status information of the registers in the corresponding hardware module based on the information in the DCC configuration parameter file.

[0122] The above-described parsing and configuration of the DCC configuration parameter file allows the Cloud Push DCC configuration parameter file to be configured into the DCC controller. This enables the DCC controller to retrieve the required register status information from the hardware modules when the fault recurs, based on the updated DCC configuration parameter file.

[0123] It is understandable that after the DCC controller is configured, it can capture the necessary register status information during the next system failure. It is also understandable that the process of the DCC controller capturing the register status is executed by the mobile phone. Figure 8 As shown, the process by which the DCC controller captures the register state may include:

[0124] S810, a system malfunction has been detected in the phone.

[0125] It is understandable that malfunctions in a mobile phone system can include system failures caused by problems with hardware modules in the phone, such as detecting address access errors, sleep / wake-up issues, CPU core hangup (CPUCORE HUNG), and so on.

[0126] S820, the operating system enters DUMP state.

[0127] As can be understood, the DUMP state is the state in which the operating system begins generating a DUMP file, thereby recording critical data such as the memory state and register state of the system when an error occurs. The DUMP file is equivalent to the fault log in this application.

[0128] The S830 DCC controller captures the relevant information.

[0129] It is understandable that the SoC chip in the mobile phone will start the DCC controller. The DCC controller will capture the status information of the CPU and bus registers, and will also capture the status information of the registers of each component in the corresponding hardware module according to the configured DCC configuration parameter file.

[0130] S840 parses the information captured by the DCC controller.

[0131] Understandably, software such as Trace32 can be used to parse the relevant information captured by the DCC controller, thereby identifying the problematic hardware module and the specific components within that module based on the parsing results.

[0132] It is understood that the configuration method in this application can also be applied to other scheduling or location scenarios, such as scenarios where certain configuration information needs to be updated, and when the problem is reproduced, the corresponding data is captured through the updated configuration information, and the corresponding data is used for location or scheduling.

[0133] For example, in Figure 3 In the dynamic switch configuration management module 310, dynamic switches applicable to other application scenarios can be configured, such as the Ftrace capture switch, iPCB maintenance and testing switch, and SSR to FULLDUMP switch. Correspondingly, the cloud configuration server 340 can configure the corresponding configuration parameter file module, and the edge-side parsing service 370 can configure the corresponding configuration service module. Specifically, the Ftrace capture switch is used to update configuration parameters for tracking and collecting function calls and execution during kernel runtime; the iPCB maintenance and testing switch is used to update configuration parameters for detecting iPCB hardware modules; and the SSR DUMP to FULLDUMP configuration switch, i.e., the subsystem restart (SSR) to full dump (FULLDUMP) configuration switch, is used to update configuration parameters when converting a subsystem restart to a full dump.

[0134] In this embodiment of the application, no specific limitations are made on the application scenario of using a method that automatically downloads the configuration parameter file pre-stored in the cloud server from the cloud side, completes the configuration, and updates the configuration information.

[0135] refer to Figure 9 , Figure 9 This is a schematic diagram of the structure of a mobile phone 100 provided in an embodiment of this application. The mobile phone 100 can be the electronic device mentioned in the above embodiments.

[0136] Mobile phone 100 may include processor 110, external memory interface 120, internal memory 121, USB interface 130, charging management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, buttons 190, motor 191, indicator 192, camera 193, display screen 194, and 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.

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

[0138] Processor 110 may include one or more processing units, such as an application processor (AP), a modem, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors. Processor 110 may also include memory for storing instructions and data. Processor 110 can be used to execute the configuration methods described in the embodiments of this application.

[0139] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in mobile phone 100 can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0140] The mobile communication module 150 can provide solutions for wireless communication applications including 2G / 3G / 4G / 5G on the mobile phone 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low-noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0141] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the 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 an audio device (not limited to speaker 170A, receiver 170B, etc.) 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 housed in the same device as the mobile communication module 150 or other functional modules. In some embodiments, the mobile phone 100 may include two modem processors, one corresponding to 4G and the other to 5G, or each corresponding to a different network standard.

[0142] The wireless communication module 160 can provide solutions for wireless communication applications on the mobile phone 100, including wireless local area networks (WLAN), such as wireless fidelity (Wi-Fi) networks, and Bluetooth (BT). The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0143] The mobile phone 100 implements 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 is used to perform mathematical and geometric calculations and for graphics rendering. The processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0144] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel.

[0145] Mobile phone 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194, and application processor. The ISP processes data fed back by camera 193. Camera 193 captures still images or videos. The digital signal processor processes digital signals, including digital image signals and other digital signals. The video codec is used to compress or decompress digital video.

[0146] Internal memory 121 can be used to store executable program code, including instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.

[0147] The mobile phone 100 can achieve audio functions such as music playback and recording through the audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0148] The pressure sensor 180A is used to sense pressure signals and can convert the pressure signals into electrical signals. In some embodiments, the pressure sensor 180A may be disposed in the display screen 194.

[0149] Touch sensor 180K, also known as a "touch panel," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of mobile phone 100, in a different position than display screen 194.

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

[0151] The various embodiments of the mechanisms disclosed in this application can be implemented in hardware, software, firmware, or a combination of these implementation methods. Embodiments of this application can be implemented as computer programs or program code executable on a programmable system, the programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0152] Program code can be applied to input instructions to execute the functions described in this application and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0153] The program code can be implemented using a high-level procedural language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used when needed. In fact, the mechanisms described in this application are not limited to any particular programming language. In either case, the language can be a compiled language or an interpreted language.

[0154] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored thereon on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed via a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, including but not limited to floppy disks, optical disks, CD-ROMs, magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in the form of electrical, optical, acoustic, or other propagation signals. Therefore, machine-readable media include any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0155] In the accompanying drawings, some structural or methodological features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be necessary. Rather, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. Furthermore, the inclusion of structural or methodological features in a particular figure does not imply that such features are required in all embodiments, and in some embodiments, these features may be omitted or may be combined with other features.

[0156] It should be noted that all units / modules mentioned in the device embodiments of this application are logical units / modules. Physically, a logical unit / module can be a physical unit / module, a part of a physical unit / module, or a combination of multiple physical units / modules. The physical implementation of these logical units / modules themselves is not the most important factor; the combination of functions implemented by these logical units / modules is the key to solving the technical problems proposed in this application. Furthermore, to highlight the innovative aspects of this application, the above-described device embodiments of this application have not introduced units / modules that are not closely related to solving the technical problems proposed in this application. This does not mean that the above-described device embodiments do not contain other units / modules.

[0157] While the invention has been illustrated and described with reference to certain preferred embodiments thereof, those skilled in the art will understand that various changes in form and detail may be made therein without departing from the scope of the invention.

Claims

1. A configuration method applied to a first electronic device including a first controller, characterized in that, include: The configuration parameter file of the first controller is obtained from the second electronic device. The configuration parameter file includes the acquisition instruction of the fault-related parameters corresponding to the first hardware module in the first electronic device and the storage address of the fault-related parameters. The first controller is a data capture and comparison engine DCC controller. The fault-related parameters include the status information of the registers of the first hardware module. The first hardware module is the module in the first electronic device related to the first fault. The first fault is a system fault caused by a problem with the hardware module. Configure the configuration parameter file into the first controller; Upon detecting the first fault in the first electronic device, the first controller is controlled to retrieve the fault-related parameters from the storage address of the fault-related parameters based on the retrieval instruction of the fault-related parameters in the configuration parameter file; The step of obtaining the configuration parameter file of the first controller from the second electronic device includes: Upon receiving the first download instruction and the first configuration instruction sent by the second electronic device, as well as the first authorization instruction of the user's first fault log, the configuration parameter file of the first controller is downloaded from the second electronic device. The first configuration instruction indicates that the DCC configuration switch and the file switch in the second electronic device are configured to be in the open state. The first download instruction is used to instruct the first electronic device to download the configuration parameter file. The first configuration instruction is used to instruct the first electronic device to configure the configuration parameter file into the first controller. The step of configuring the configuration parameter file into the first controller includes: In response to the first configuration instruction, it is determined that the configuration parameter file meets the configuration conditions, wherein the configuration conditions include the version number of the configuration parameter file being a first version number, and the configuration parameter file corresponding to the model of the first electronic device; Shut down the engine of the first controller; Clear the configuration parameters stored in the first controller; Write the contents of the configuration parameter file to the memory address corresponding to the first controller; Set the operating mode of the first controller to capture mode; Start the engine of the first controller.

2. The method according to claim 1, characterized in that, The first download instruction includes the storage path and key of the configuration parameter file, and the step of downloading the configuration parameter file of the first controller from the second electronic device includes: Based on the key, the configuration parameter file of the first controller is downloaded from the storage path of the second electronic device.

3. The method according to claim 1, characterized in that, The method further includes: Set the memory address where the first fault log is stored.

4. The method according to claim 1, characterized in that, The first electronic device is detected to have a first fault. The first controller is controlled to retrieve the fault-related parameters from the storage address of the fault-related parameters based on the retrieval instruction in the configuration parameter file, including: A first malfunction was detected in the first electronic device; The first controller is controlled to perform detection based on the configuration parameter file and obtain the first fault log including the fault-related parameters.

5. A chip comprising a processor that executes stored computer instructions, which, when executed on an electronic device, cause the electronic device to perform the method of any one of claims 1 to 4.

6. A computer-readable storage medium, characterized in that, The readable storage medium stores instructions that, when executed on an electronic device, cause the electronic device to perform the method of any one of claims 1 to 4.

7. An electronic device, characterized in that, include: Memory is used to store instructions executed by one or more processors of an electronic device; And a processor, one of the processors of the electronic device, for executing instructions stored in the memory to implement the method of any one of claims 1 to 4.

Images