Driving problem analysis method

Abstract

The invention discloses a drive problem analysis method, which is applied to a first electronic device, the first electronic device comprises a software drive unit and a first memory, a drive program is stored in the software drive unit, the drive program comprises a global variable, and the method comprises the following steps: in the process of executing the drive program by the first memory, executing the global variable by the first memory; protocol data are recorded through the global variable, the protocol data are analyzed under the condition that the first memory is abnormal, and the protocol data are data generated in the running process of the drive program. According to the method, the protocol data is acquired in the case of abnormity in a software mode, a hardware method is not needed to analyze problems, a problem site can be reserved in time, and the problem analysis efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the field of electronic technology, and in particular to a method for analyzing a driving problem, an electronic device and a computer-readable storage device. Background Art

[0002] In consumer electronic mobile devices, embedded MultiMediaCard (eMMC) storage module is one of the common storage media, widely used in smartphones, tablets and other portable devices. However, due to the high-frequency operation and complex data exchange process of eMMC storage module, it may also encounter various problems in actual application, such as data read errors, write failures, speed drops, etc. These problems often have a serious impact on user experience and device performance.

[0003] In the prior art, fault diagnosis of eMMC storage modules requires physical equipment, such as capturing eMMC protocol data through a protocol analyzer. The traditional diagnostic process usually relies on manually connecting the protocol analyzer to the eMMC interface of the device and capturing data when a problem occurs. If no problem is found, the device needs to be connected again to recapture data. This process is cumbersome and time-consuming, costly, and difficult to capture fault data in real time. Summary of the invention

[0004] The embodiment of the present application discloses a method for analyzing a drive problem, which obtains protocol data in an abnormal situation by software, without having to analyze the problem by hardware method. This not only can preserve the problem site in time, but also improves the efficiency of analyzing the problem.

[0005] A first aspect of an embodiment of the present application discloses a method for analyzing a driver problem, which is applied to a first electronic device, wherein the first electronic device includes a software driver unit and a first memory, wherein the software driver unit stores a driver program, and the driver program includes a global variable, and the method includes:

[0006] During the process of executing the driver program in the first memory, protocol data is recorded through the global variable so as to analyze the protocol data when an abnormality occurs in the first memory. The protocol data is data generated during the operation of the driver program.

[0007] As an optional implementation manner, in the first aspect of this embodiment, the first electronic device further includes a second memory, and recording the protocol data through the global variable includes:

[0008] During the process of executing the driver program in the first memory, the protocol data is recorded in the second memory through the global variable.

[0009] As an optional implementation, in the first aspect of this embodiment, the second memory is a double data rate memory.

[0010] As an optional implementation, in the first aspect of this embodiment, when an abnormality occurs in the first memory, the driver is triggered to terminate operation, and the protocol data is at least part of the protocol data before the driver is terminated.

[0011] As an optional implementation manner, in the first aspect of this embodiment, the protocol data is sent to a second electronic device so that the second electronic device performs data analysis on the protocol data.

[0012] As an optional implementation, in the first aspect of this embodiment, the driver further includes data embedding points, and the recording of protocol data through the global variable further includes:

[0013] During the process of executing the driver program in the first memory, the protocol data recorded by the global variable is obtained through the data embedding point.

[0014] As an optional implementation, in the first aspect of this embodiment, the first memory is an embedded multimedia card.

[0015] As an optional implementation manner, in the first aspect of this embodiment, the global variable includes at least one of the following:

[0016] A first global variable, used to record the execution order of the commands of the driver program;

[0017] A second global variable is used to record the content of the parameter of the command of the driver program;

[0018] A third global variable is used to record the error code content after the command of the driver is executed;

[0019] The fourth global variable is used to record the number of commands executed before the current command of the driver program.

[0020] A second aspect of an embodiment of the present application discloses an electronic device, including a first memory and a software driving unit, wherein:

[0021] The software driver unit is used to store the driver program, and to record protocol data through the global variable during the process of executing the driver program in the first memory, so as to analyze the protocol data when an abnormality occurs in the first memory, wherein the protocol data is data generated during the operation of the driver program;

[0022] The first memory is used to execute the driver program.

[0023] A third aspect of an embodiment of the present application is a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, any of the above-mentioned drive problem analysis methods is implemented.

[0024] Compared with the related art, the embodiments of the present application include at least the following beneficial effects:

[0025] The present application discloses a method for analyzing a driver problem, which is applied to a first electronic device, wherein the first electronic device includes a software driver unit and a first memory, wherein a driver program is stored in the software driver unit, and the driver program includes global variables, and the method includes: in the process of executing the driver program in the first memory, protocol data is recorded through global variables, so as to analyze the protocol data when an abnormality occurs in the first memory, and the protocol data is data generated during the operation of the driver program. The method obtains the protocol data in an abnormality by software, and does not need to analyze the problem by hardware methods, which can not only retain the problem site in time, but also improve the efficiency of analyzing the problem. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0027] Figure 1 A schematic diagram of a first electronic device provided in an embodiment of the present application;

[0028] Figure 2 A flow chart of a driving problem analysis method provided in an embodiment of the present application;

[0029] Figure 3 A flow chart of another driving problem analysis method provided in an embodiment of the present application;

[0030] Figure 4 A schematic diagram of another first electronic device provided in an embodiment of the present application;

[0031] Figure 5 A flow chart of another driving problem analysis method provided in an embodiment of the present application;

[0032] Figure 6 A flow chart of another driving problem analysis method provided in an embodiment of the present application;

[0033] Figure 7A flow chart of another driving problem analysis method provided in an embodiment of the present application;

[0034] Figure 8 A schematic diagram of another first electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0035] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0036] It should be pointed out that the terms "first\second\third" involved in the embodiments of the present application are used to distinguish similar or different objects, and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0037] It should be noted that the terms "including" and "having" and any variations thereof in the embodiments of the present application and the accompanying drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device including a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products or devices.

[0038] In consumer electronic mobile devices, embedded MultiMediaCard (eMMC) storage module is one of the common storage media, widely used in smart phones, tablets and other portable devices. However, due to the high-frequency operation and complex data exchange process of eMMC storage module, it may also encounter various problems in actual application, such as data read errors, write failures, speed drops, etc. These problems often have a serious impact on user experience and device performance.

[0039] In the prior art, fault diagnosis for eMMC storage modules requires physical devices, such as protocol analyzers, to capture eMMC protocol data. Protocol analyzers can accurately record the data stream on the eMMC bus, including the commands sent, the responses received, and other protocol interaction information (such as error status, timing problems, etc.). This information can help engineers understand whether there is an abnormality in the communication between the eMMC module and the main control chip, and whether data loss or other problems are caused by protocol errors or hardware failures. However, the operator of this method needs to connect the probe of the protocol analyzer to the eMMC interface of the device through a flying line to ensure that the data of the eMMC communication can be captured in real time. Then, the tester must reproduce the faulty or erroneous operation on the device in order to capture the relevant protocol data. This process has the disadvantages of being cumbersome and time-consuming, difficult to capture fault data in real time, unable to monitor for a long time, and high cost and low efficiency.

[0040] Among them, the cumbersome and time-consuming operation means that since most consumer electronic devices are not designed with a dedicated PA interface, engineers usually need to manually connect the protocol analyzer to the eMMC interface of the device after a problem occurs. This process not only consumes a lot of time, but may also require the device to be disassembled in order to connect the flying wire. It is difficult to capture fault data in real time. The protocol analyzer can only start recording data after the flying wire connection is completed, but the timing of the fault is usually difficult to predict. When a fault occurs, if the protocol analyzer is not connected in time, key protocol interaction data may be missed, resulting in the inability to fully reproduce the problem. The inability to monitor for a long time means that most devices will not be continuously connected to the protocol analyzer during normal use, so the protocol status of the eMMC cannot be continuously monitored during the use of the device. High cost and low efficiency means that manually connecting the protocol analyzer requires a lot of manpower and material resources, including disassembling the device, connecting the flying wire, configuring the test environment, etc., which makes this method costly and the entire process inefficient.

[0041] Based on this, an embodiment of the present application discloses a method for analyzing a driving problem, which can solve the above problems. The analysis method of the embodiment of the present application is applied to a first electronic device, the first electronic device includes a software driver unit and a first memory, the software driver unit stores a driver program, the driver program includes global variables, and the method includes: in the process of executing the driver program in the first memory, the protocol data is recorded by the global variables, so as to analyze the protocol data when an abnormality occurs in the first memory, and the protocol data is the data generated during the operation of the driver program. The method obtains the protocol data by software in the event of an abnormality, and there is no need to analyze the problem by hardware methods. It can not only keep the problem site in time, but also improve the efficiency of analyzing the problem. The following are detailed descriptions.

[0042] The driving method disclosed in the embodiments of the present application can be applied to different types of electronic devices. For example, the electronic devices may include smart phones, tablet computers, wearable devices, embedded devices, automotive electronics, industrial automation equipment, computer hardware, servers, consumer electronics, and medical devices, etc., without specific limitation.

[0043] The analysis of driving problems of the above-mentioned different types of electronic devices is described in detail below. For example, in smartphones and tablets, this method can be applied to abnormal analysis of screens, cameras, Wi-Fi modules, etc. in smartphones, tablets, wearable devices, etc. For another example, in embedded devices, this method can be applied to hardware problem analysis of devices in the fields of automation control, Internet of Things devices, smart homes, etc. For another example, in the field of automotive electronics, this method can be applied to driving problem analysis in systems such as in-vehicle entertainment systems, automatic driving systems, and power system management. For another example, in industrial automation equipment, this method can be applied to driving problem analysis in devices such as robots, programmable logic controllers, sensors, and actuators on automated production lines. For another example, in computer hardware and servers, this method can be applied to hardware drivers in servers and high-performance computers, such as network card drivers, hard disk drivers, etc., without specific restrictions here. For another example, in consumer electronic products, this method can be applied to driving problem analysis in devices such as digital cameras and game consoles. For another example, in medical equipment, this method can be applied to driving problem analysis in devices such as electrocardiographs and ventilators.

[0044] See also Figure 1 , Figure 1 A schematic diagram of a first electronic device provided in an embodiment of the present application. The electronic device includes a software driver unit 11 and a first memory 12, wherein a driver program 111 is stored in the software driver unit, and the driver program includes global variables. In order to more clearly understand the above method, the embodiment of the present application is described with the first electronic device as the execution subject. It should be understood that the execution subject of the embodiment of the present application can be a chip or a processor in the first electronic device, etc., and no limitation is made here.

[0045] See also Figure 2 , Figure 2 A flowchart of a driving problem analysis method provided in an embodiment of the present application, the flowchart at least includes the following steps S101-S102:

[0046] Step S101: The first electronic device executes a driver program through the first memory;

[0047] Step S102: the first electronic device records protocol data through global variables during the process of executing the driver program 111 in the first memory 12, so as to analyze the protocol data when an abnormality occurs in the first memory, and the protocol data is the data generated during the operation of the driver program.

[0048] Among them, the driver is the intermediary software between the computer operating system and the hardware device, which allows the operating system to communicate and interact with the hardware device. Each hardware device has a specific driver to process the instructions sent by the operating system to the hardware and perform corresponding operations. Without a suitable driver, the hardware cannot be recognized and used by the operating system.

[0049] Drivers can include hardware abstraction, hardware control, and data exchange. Hardware abstraction means that the driver abstracts the operating details of the hardware device and provides a standard interface so that the operating system and application programs can control the hardware through the driver instead of directly operating the hardware. Hardware control means that the driver is responsible for directly controlling the working status of the hardware device, such as starting, stopping, configuring, and error detection. Data exchange means that the driver is responsible for transferring data between the hardware and the operating system.

[0050] The working principle of a driver includes several steps, such as operating system request, driver processing, hardware response, and operating system processing results.

[0051] Among them, the operating system request refers to the request sent by the operating system through the driver when the user or operating system needs to interact with the hardware. Driver processing refers to the driver converting the request into instructions that the hardware can understand after receiving it. Hardware response refers to the hardware executing the instruction and feeding back the result to the driver. The operating system processing result refers to the driver returning the hardware response data to the operating system or application, and the operating system further processes it according to the result.

[0052] The first memory mentioned in the above steps is a hardware component in the computer, which is used to store data and program instructions. It is an indispensable part of the computer system, responsible for storing data, programs and part of the operating system information required when the computer is running. In the embodiment of the present application, the first memory can be used to execute the command of the driver.

[0053] According to the access method of memory, memory can be divided into two categories, namely, random access memory (RAM) and read-only memory (ROM). Among them, RAM is a temporary memory used to store data and programs that need to be accessed when the computer is running. This type of memory is volatile, that is, the data in it will be lost after the computer is turned off. ROM is used to store fixed programs and data, which are usually unchangeable or can only be updated through special methods. This type of memory is non-volatile, and the stored data will not be lost even if the computer is turned off.

[0054] Based on the above classification of memories, optionally, the first memory of the present application may be a RAM memory. In this way, since the RAM memory has a faster reading and writing speed, the protocol data can be quickly recorded and updated, thereby reducing the risk of data loss.

[0055] Optionally, the first memory of the present application may also be a ROM memory, so that data can be saved even in a power outage, making it easy to perform retrospective analysis on abnormal data.

[0056] A global variable is a variable that is declared and defined outside of all functions in a program. It is accessible throughout the life of the program, and its scope usually covers the entire file or program. It can be read and modified by any function in the program unless it is overwritten by a local variable in the local scope. In addition, global variables can share data between different functions, so they are very useful for data transfer between different functions.

[0057] In this embodiment, the global variables may include a first global variable, a second global variable, a third global variable, and a fourth global variable.

[0058] Wherein, the first global variable is used to record the execution order of the driver program's commands;

[0059] The second global variable is used to record the content of the parameters of the driver program's command;

[0060] The third global variable is used to record the error code content after the driver's command is executed;

[0061] The fourth global variable is used to record the number of commands executed before the current command of the driver.

[0062] Therefore, during the operation of the driver program, the content of the parameters of the driver program's commands, the content of the parameters of the driver program's commands, and the number of commands executed before the driver program's current command can be recorded through global variables.

[0063] Optionally, the global variables may be adjusted according to actual needs, for example, by increasing or decreasing the global variables to increase or decrease the type of recorded data, so that the method has more flexibility and adaptability.

[0064] In this method, during the execution of the driver, the electronic device records the protocol data in real time by setting global variables. These protocol data are generated during the operation of the driver. When an exception occurs in the first memory, the system can track and analyze the protocol data that have been recorded in the global variables. In this way, the cause of the exception can be found from these data, so as to analyze and debug the behavior of the first memory in detail. In addition, by setting global variables in the software driver unit, the protocol data of the first memory card in the process of executing the command of the driver is recorded, so that there is no need to use physical hardware devices to obtain protocol data, which solves the problem that the physical hardware device needs to be connected to the memory card interface of the faulty device through a flying line when obtaining the protocol data, which causes the operation to be cumbersome and time-consuming. In addition, the method records a large amount of data by software, and analyzes the obtained protocol data when an exception occurs in the memory. At this time, a large amount of protocol data has been recorded and retained, which avoids the problem that the physical hardware device fails to obtain the protocol data in time, resulting in the inability to obtain the abnormal protocol data in time even if the faulty device is connected.

[0065] In the embodiment of the present application, the protocol data may be analyzed by the first electronic device mentioned above to analyze the fault, or other electronic devices (such as the second electronic device) may analyze the protocol data to analyze the fault, and the embodiment of the present application does not impose any limitation.

[0066] In one embodiment, the first electronic device analyzes the protocol data to analyze the fault. Exemplarily, the first electronic device can display the protocol data on the display screen of the first electronic device in the form of a text file or a window display, and the staff can view the abnormal data and analyze the abnormal data. It can be understood that in this case, the first electronic device is an electronic device with a display screen, or the first electronic device includes a software device that can analyze the drive problem. In the event of an abnormality in the memory, the software device can automatically download the protocol data to analyze the protocol data.

[0067] In another embodiment, the second electronic device obtains protocol data from the first electronic device, and analyzes the protocol data to analyze the fault.

[0068] In one example, an external storage device (such as a USB flash drive) is used to obtain protocol data during the operation of a driver program from a first electronic device, and the data is imported into a second electronic device through the external storage device so that the second electronic device obtains the protocol data, and then the second electronic device automatically analyzes the problem of the protocol data, or opens the protocol data by screen display, and the staff can view and analyze the protocol data to find the problem. It can be understood that when the staff views and analyzes the protocol data, the other device is a device with a display screen.

[0069] In another example, a first device and a second device are connected, the first device sends data to the second device, the second device opens the protocol data in the form of a text file or a display window, and analyzes the protocol data to analyze the fault. For example, to more clearly understand the method, please refer to Figure 3 , Figure 3 Another driving problem analysis method flow chart provided in an embodiment of the present application includes at least the following steps S201-S203:

[0070] Step S201: the first electronic device executes a driver program through the first memory;

[0071] Step S202: the first electronic device records the protocol data through the global variable during the process of executing the driver program 111 in the first storage 12;

[0072] Step S203: the first electronic device sends the protocol data to the second electronic device so that the second electronic device performs data analysis.

[0073] The second electronic device opens the protocol data in the form of a text file or a display window, and the user can view and analyze the protocol data in real time.

[0074] In one embodiment, when the second electronic device opens the protocol data in the form of a text file, the method may be: the first electronic device records the protocol data through global variables during the process of executing a driver program in the first memory, and the protocol data at least records the content of the parameters of the driver program's command, the content of the parameters of the driver program's command, and the number of commands executed before the driver program's current command through global variables. When an abnormality occurs in the first memory, the first electronic device sends the obtained protocol data to the second electronic device in the form of a text file, and the second electronic device opens the text file to perform data analysis on the obtained protocol data.

[0075] In another embodiment, when the second electronic device views the protocol data in the form of a display window, the method may be: during the process of the first electronic device executing the driver program in the first memory, the first electronic device records the protocol data through global variables, and the protocol data at least includes the content of the parameters of the driver program's command, the content of the parameters of the driver program's command, and the number of commands executed before the driver program's current command recorded through global variables; when an abnormality occurs in the first memory, the first electronic device sends the obtained protocol data to the second electronic device, and the protocol data is displayed in the display window of the second electronic device, and the user can perform data analysis on the obtained protocol data through the display window of the second electronic device.

[0076] In this method, the first electronic device can be connected to the second electronic device. When an abnormality occurs in the first memory of the first electronic device, the first electronic device automatically sends the acquired protocol data to the second electronic device. The second electronic device can check the abnormal status of the first electronic device in real time, thereby performing more effective abnormality analysis.

[0077] In some embodiments, see Figure 4 , Figure 4 Schematic diagram of another first electronic device provided in an embodiment of the present application. The first electronic device also includes a second memory 13, and the second memory 13 is used to store protocol data. With respect to step S102, the protocol data is recorded through a global variable, which can be:

[0078] During the process of executing the driver program in the first memory, the first electronic device records the protocol data in the second memory through the global variable.

[0079] To understand the above method more clearly, see Figure 5 , Figure 5 Another driving problem analysis method flow chart provided in an embodiment of the present application includes at least the following steps S302-S303:

[0080] Step S301: the first electronic device executes a driver program through the first memory;

[0081] Step S302: the first electronic device records protocol data in the second memory 13 through global variables during the process of executing the driver program 111 in the first memory 12, so as to analyze the protocol data when an abnormality occurs in the first memory 12.

[0082] In one example, during the process of executing a driver program in a first memory, a first electronic device records protocol data during the operation of the first memory through global variables in the driver program, and stores these protocol data on a second memory. When an abnormality occurs in the first memory, the protocol data stored on the second memory is obtained and the protocol data is analyzed to analyze the problems that occurred during the operation of the first memory.

[0083] In another example, when protocol data is stored in the second memory and the protocol data is sent to the second electronic device through the first electronic device, the method is: the first electronic device records the protocol data through global variables during the process of executing the driver program in the first memory, and the protocol data is at least the content of the parameters of the driver program command, the content of the parameters of the driver program command, and the number of commands executed before the current command of the driver program recorded through the global variables, and the data recorded through the global variables is stored in the second memory. When an abnormality occurs in the first memory, the driver program is triggered to terminate, and the protocol data before the driver program is terminated is obtained. The protocol data is the data recorded on the second memory through the global variables. Then the first electronic device sends the protocol data to the second electronic device for data analysis by the second electronic device.

[0084] Optionally, the second memory can be a volatile memory. Since volatile memory usually has a faster read and write speed, it can quickly record and update protocol data, thereby reducing the risk of data loss. For example, using volatile memory such as RAM, a large amount of data can be captured and stored in real time during the operation of the driver. In addition, the cost of volatile memory is usually lower than that of non-volatile memory, which allows a more economical storage solution to be used when the storage space requirement is not high.

[0085] Optionally, the second memory can also be a non-volatile memory, which has the advantages of data persistence, reliable data storage, more suitable for long-term storage, larger storage space, and reduced data recovery costs compared to volatile memory. In scenarios where long-term analysis and archiving of protocol data are required, such as embedded systems, industrial equipment, automotive electronics and other fields, it is very beneficial for driver debugging, troubleshooting and system performance optimization.

[0086] In addition, in this method, the protocol data stored in the second memory can be conveniently backed up, archived or further analyzed and processed, and can provide valuable information for subsequent performance evaluation, optimization, etc.

[0087] In some embodiments, the second memory may be a double data rate memory.

[0088] Double Data Rate SDRAM (DDR) is mainly used for dynamic random access memory in electronic products such as computers, servers, and mobile devices. Compared with traditional synchronous dynamic random access memory, the improvement of DDR memory is mainly reflected in the data transmission method. In traditional synchronous dynamic random access memory, data can only be transmitted on one edge (rising or falling) of the clock signal; while DDR memory transmits data once on the rising edge and falling edge of the clock signal. This allows DDR memory to transmit twice as much data at the same clock frequency.

[0089] Optionally, DDR has multiple versions, for example, DDR2, DDR3, DDR4 and DDR5, without specific limitation here, wherein each version of DDR is improved on the basis of the previous version, and the current newer version of DDR5 has wider bandwidth and energy efficiency, supports higher capacity memory modules, and meets the needs of future data centers and high-performance computing, but the price of newer versions of DDR memory will be higher, therefore, when choosing DDR, you can choose according to actual needs.

[0090] Exemplarily, during the process of the first electronic device executing a driver program in the first memory, the global variables in the driver program record the protocol data during the operation of the first memory, and store these protocol data in the double data rate memory. When an abnormality occurs in the first memory, the protocol data stored in the double data rate memory is obtained and the protocol data is analyzed to analyze the problems that occurred during the operation of the first memory.

[0091] In this method, double data rate memory is used to store protocol data about the first memory operation process recorded by global variables during the operation of the driver program. Since double data rate memory has a higher transmission rate and lower energy consumption, the memory responds more quickly when executing the driver program and obtaining protocol data, thereby improving the performance of the overall system. In addition, since DDR memory technology has been widely supported and applied to modern computer systems, it has good market compatibility and supply chain stability. Therefore, the use of DDR memory can ensure the operation of drivers for different hardware platforms.

[0092] In some embodiments, when an abnormality occurs in the first memory, the first electronic device triggers the driver to terminate operation, and the acquired protocol data is at least part of the protocol data before the driver terminates. Figure 6 , Figure 6 Another driving problem analysis method flow chart provided in an embodiment of the present application includes at least the following steps S401-S403:

[0093] Step S401: the first electronic device executes a driver program through the first memory;

[0094] Step S402: the first electronic device records the protocol data on the first storage device 111 through global variables during the process of executing the driver program 111 in the first storage device 112;

[0095] Step S403: When an abnormality occurs in the first memory 12, the first electronic device triggers the driver program to terminate.

[0096] The protocol data in step S403 is at least part of the protocol data before the driver program is terminated.

[0097] In one embodiment, the data recorded on the global variables in the first electronic device is stored on the second memory. The method may be: during the process of the first electronic device executing a driver program in the first memory, the protocol data is recorded on the second memory through the global variables; when an abnormality occurs in the first memory, the driver program is triggered to terminate, and the protocol data before the driver program is terminated is obtained to analyze the protocol data, where the protocol data is at least part of the protocol data before the driver program is terminated.

[0098] In this method, storing the protocol data in the second memory can ensure that the data will not be lost when an abnormality occurs in the first memory. This independence improves the reliability of the data and facilitates subsequent analysis and troubleshooting. In addition, by recording the protocol data during the operation of the driver, when an abnormality occurs in the first memory, the data can be quickly obtained after the driver is terminated, helping developers to effectively analyze the cause of the fault and the operating status, thereby speeding up the diagnosis and resolution of the problem. In addition, the protocol data stored in the second memory can be easily backed up, archived, or further analyzed and processed, which can provide valuable information for subsequent performance evaluation, optimization, etc.

[0099] It should be understood that the above process of recording the protocol data on the second memory through the global variable is only an illustrative description, and the embodiments of the present application are not limited thereto. In other embodiments, the first electronic device may also record the protocol data on the first memory through the global variable.

[0100] Optionally, the method can adjust the data storage strategy as needed, such as adding more monitoring data or changing the data storage format, to enhance the flexibility and adaptability of the system.

[0101] In some embodiments, the driver program also includes data embedding points. In the process of the first electronic device executing the driver program in the first memory in step S101, the protocol data is recorded through global variables, which can be:

[0102] During the process of executing the driver program in the first memory, the first electronic device obtains the protocol data recorded in the global variable through data embedding.

[0103] For a more detailed explanation of the above steps, see Figure 7 , Figure 7 Another driving problem analysis method flow chart provided in an embodiment of the present application includes at least the following steps S501-S503:

[0104] Step S501: the first electronic device executes a driver program through the first memory;

[0105] Step S502: During the process of executing the driver program 111 in the first storage 12, the first electronic device obtains the protocol data recorded in the global variable through data embedding.

[0106] The data tracking in this process step refers to some pre-set codes or mechanisms in the software system, website or application to collect, record and track data of user behavior or system events. Data tracking can be used for data collection, event tracking, etc.

[0107] Data collection in data tracking refers to capturing data at a specific location through tracking code. In this method, the acquired data tracking information can be commands, parameters, and error codes, etc. Event tracking in data tracking means that each tracking point usually corresponds to a specific event, and these events will be recorded.

[0108] Optionally, data embedding can be done manually, automatically, or by a combination of methods. There is no specific limitation here, and the method can be selected based on actual needs.

[0109] Among them, manual data tracking is the code or software development kit that developers explicitly add data collection to the code, usually manually writing event tracking code at specific function points, pages or user interactions. This method can accurately control the data type and format of the collected data, and is suitable for specific business needs. However, manual tracking has a long development cycle, high maintenance costs, and requires the participation of developers, making it difficult to flexibly respond to changes in demand.

[0110] Automatic data tracking is the process of automatically collecting user behavior data in applications through third-party analysis tools or software development kits, without the need for developers to manually write each data tracking point. The automatic data tracking method has the advantages of simple deployment and maintenance, the ability to quickly capture large amounts of user behavior data, and reduced manual intervention. However, it has poor flexibility and may capture a lot of unnecessary data, leading to data overload or performance issues.

[0111] Hybrid data tracking combines the advantages of manual tracking and automatic tracking. Most common user behaviors can be collected through automatic tracking, while some specific business logic (such as special button clicks, specific event triggers) use manual tracking. The hybrid tracking method can reduce the development workload while ensuring accurate tracking of specific behaviors.

[0112] In one embodiment, the first electronic device can store protocol data through the second memory, and the method is: during the process of the first electronic device executing the driver program in the first memory, the protocol data recorded by the global variable is obtained through the data burying point, and the data recorded by the global variable obtained through the data burying point is stored in the second memory. When an abnormality occurs in the first memory, the driver program is triggered to terminate, and the protocol data before the driver program is terminated is obtained. The protocol data is the data recorded by the global variable obtained through the burying point on the second memory, and the protocol data is part of the protocol data obtained through the data burying point before the driver program is terminated. Then the first electronic device sends the protocol data to the second electronic device to perform data analysis through the second electronic device.

[0113] Optionally, the second electronic device may open the protocol data for analysis in the form of a text file and a display window. It is understandable that, in this case, the second electronic device has a display screen.

[0114] In one embodiment, when the first electronic device stores protocol data through the second memory, and the second electronic device opens the protocol data in the form of a text file, the method may be: during the process of the first electronic device executing the driver program in the first memory, the protocol data recorded by the global variables is obtained through data burying, and the data recorded by the global variables obtained through the data burying is stored in the second memory. When an abnormality occurs in the first memory, the driver program is triggered to terminate, and the protocol data before the driver program is terminated is obtained. The protocol data is the data recorded by the global variables obtained through the burying on the second memory, and the protocol data is part of the protocol data obtained through the data burying before the driver program is terminated. Then the first electronic device sends the obtained part of the protocol data to the second electronic device in the form of a text file, and the second electronic device opens the text file to perform data analysis on at least part of the obtained protocol data.

[0115] In another embodiment, when the first electronic device stores protocol data through the second memory, and the second electronic device opens the protocol data in the form of a display window, the method may be: in the process of executing the driver program in the first memory, the protocol data recorded by the global variable is obtained through the data burying point, and the data recorded by the global variable obtained through the data burying point is stored in the second memory. When an abnormality occurs in the first memory, the driver program is triggered to terminate, and the protocol data before the driver program is terminated is obtained. The protocol data is the data recorded by the global variable obtained through the burying point on the second memory, and the protocol data is part of the protocol data obtained through the data burying point before the driver program is terminated. Then the first electronic device sends the obtained part of the protocol data to the second electronic device, and the protocol data is displayed in the display window of the second electronic device. The user can perform data analysis on at least part of the obtained protocol data through the display window of the second electronic device.

[0116] In some embodiments, the first memory is an embedded multimedia card.

[0117] Embedded MultiMediaCard (eMMC) is a storage device widely used in mobile devices, embedded systems and consumer electronics. eMMC chip is a memory card based on NAND flash memory technology, usually soldered to the device motherboard, suitable for devices requiring embedded storage, such as smartphones, tablets, IoT devices, digital cameras and in-car entertainment systems.

[0118] The core of the embedded multimedia card is a storage system composed of NAND flash memory and a built-in controller. Among them, NAND flash memory is the storage medium of eMMC. It stores data through electric charge. It is a non-volatile storage technology that can maintain data in the case of power failure. The controller is a controller integrated inside the eMMC, which is responsible for managing the read and write requests of the storage medium. The controller will handle various complex tasks in the background, such as bad block management, data erasure, write amplification effect, etc. Due to the high performance of embedded multimedia cards, and the advantages of low power consumption, miniaturization and high integration, they are widely used in various devices. Therefore, this method can be used to analyze problems when the eMMC memory is abnormal, and has wide applicability.

[0119] It should be understood that the above-mentioned abnormality detection of the embedded multimedia card is only an illustrative description, and the embodiments of the present application are not limited thereto. In other embodiments, the present application can also perform abnormality detection on SD cards and UFS cards.

[0120] Optionally, the second electronic device may open the protocol data in the form of a text file and a display window for analysis.

[0121] The present application also discloses a first electronic device. Figure 8 , Figure 8 A schematic diagram of another first electronic device provided in an embodiment of the present application includes a software driver unit 11, a first memory 12, a second memory 13 and a processing unit 14, wherein a driver program 111 is stored in the software driver unit, and the driver program includes global variables, wherein:

[0122] A software driver unit 11, used for storing a driver program 111;

[0123] A first memory 12, used for executing commands of the driver program 111;

[0124] The processing unit 14 is used for: executing the driver program 111 in the first memory; and recording protocol data through global variables during the execution of the driver program 111 in the first memory 12, so as to analyze the protocol data when an abnormality occurs in the first memory 12, and the protocol data is the data generated during the operation of the driver program 111.

[0125] Optionally, the first electronic device also includes a second memory 13. In the method of recording protocol data through global variables, the second memory 13 is also used to record the protocol data on the second memory 13 through the global variables during the process of executing the driver 111 in the first memory.

[0126] Optionally, the second memory 13 may be a double data rate memory.

[0127] Optionally, the processing unit 14 is further configured to trigger the driver program 111 to terminate operation when an exception occurs in the first memory, and the protocol data is at least part of the data before the driver program 111 terminates.

[0128] Optionally, the processing unit 14 is further configured to send the protocol data to the second electronic device, so that the second electronic device performs data analysis on the protocol data.

[0129] Optionally, the driver program 111 also includes data embedding points. In the method of recording protocol data through global variables, the processing unit 14 is also used to obtain the protocol data recorded by the global variables through the data embedding points during the process of executing the driver program 111 in the first memory.

[0130] Optionally, the first memory 12 may be an embedded multimedia card.

[0131] The embodiment of the present application also discloses a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, any of the above-mentioned analysis methods for the driving problem is implemented.

[0132] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program, and the program can be stored in a non-volatile computer-readable storage medium, and when the program is executed, it can include the processes of the embodiments of the above-mentioned methods. The storage medium can be a disk, an optical disk, a ROM, etc.

[0133] As used herein, any reference to memory, storage, database, or other medium may include nonvolatile and / or volatile memory. Suitable nonvolatile memory may include ROM, programmable ROM (Programmable ROM, PROM), erasable PROM (Erasable PROM, EPROM), electrically erasable PROM (Electrically Erasable PROM, EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which is used as an external cache memory. By way of illustration and not limitation, RAM may be in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), memory bus direct RAM (RDRAM) and direct memory bus dynamic RAM (DRDRAM).

[0134] It should be understood that the "one embodiment" or "an embodiment" mentioned throughout the specification means that the specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. Those skilled in the art should also be aware that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily required for the present application.

[0135] In the various embodiments of the present application, it should be understood that the size of the serial numbers of the above-mentioned processes does not necessarily mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0136] The units described above as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0137] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0138] The term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there may be three relationships. For example, object A and / or object B can represent three situations: object A exists alone, object A and object B exist at the same time, and object B exists alone.

[0139] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0140] The methods disclosed in several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0141] The features disclosed in several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0142] The features disclosed in several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.

[0143] The above is a detailed introduction to the analysis method of the driving problem disclosed in the embodiment of the present application. The principle and implementation method of the present application are described in detail using specific examples. The description of the above embodiments is only used to help understand the method and core idea of ​​the present application. At the same time, for those of ordinary skill in the art, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A method for analyzing a driving problem, characterized in that: The method is applied to a first electronic device, wherein the first electronic device comprises a software driving unit and a first memory, wherein a driver is stored in the software driving unit, and the driver comprises a global variable; and the method comprises: Executing the driver program through the first memory; During the process of executing the driver program in the first memory, protocol data is recorded through the global variable so as to analyze the protocol data when an abnormality occurs in the first memory. The protocol data is data generated during the operation of the driver program.

2. The method according to claim 1, characterized in that The first electronic device further includes a second memory, and the recording of protocol data through the global variable includes: During the process of executing the driver program in the first memory, the protocol data is recorded in the second memory through the global variable.

3. The method according to claim 2, characterized in that The second memory is a double data rate memory.

4. The method according to claim 1, characterized in that The method further comprises: When an abnormality occurs in the first memory, the driver is triggered to terminate operation, and the protocol data is at least part of the data before the driver is terminated.

5. The method according to claim 4, characterized in that The method further comprises: The protocol data is sent to a second electronic device so that the second electronic device performs data analysis on the protocol data.

6. The method according to claim 1, characterized in that The driver program also includes data embedding points, and the protocol data is recorded through the global variable, including: During the process of executing the driver program in the first memory, the protocol data recorded by the global variable is obtained through the data embedding point.

7. The method according to claim 1, characterized in that The first memory is an embedded multimedia card.

8. The method according to claim 1, characterized in that The global variables include at least one of the following: A first global variable, used to record the execution order of the commands of the driver program; A second global variable is used to record the content of the parameter of the command of the driver program; A third global variable is used to record the error code content after the command of the driver is executed; The fourth global variable is used to record the number of commands executed before the current command of the driver program.

9. An electronic device, characterized in that: The system comprises a first memory, a software driver unit and a processing unit, wherein a driver is stored in the software driver unit, and the driver includes a global variable, wherein: The processing unit is used to: control the first memory to execute the driver program; The processing unit is also used for: recording protocol data through the global variable during the process of executing the driver program in the first memory, so as to analyze the protocol data when an abnormality occurs in the first memory, and the protocol data is the data generated during the operation of the driver program.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for analyzing a driving problem as described in any one of claims 1 to 8 is implemented.

Images