A data processing method, apparatus, device, and storage medium

Abstract

This invention discloses a data processing method, apparatus, device, and storage medium. The method includes: when a system anomaly occurs, acquiring an anomaly code corresponding to the anomaly; determining an anomaly handling method based on the type of the anomaly code; using the anomaly handling method to acquire system anomaly information corresponding to the anomaly; and locating the anomaly based on the system anomaly information to obtain a system anomaly location result. This solution improves the efficiency and accuracy of system anomaly analysis and enhances the reliability of automotive embedded controller systems.

Description

Technical Field

[0001] The present invention relates to the field of computers, and more particularly to a data processing method, apparatus, device, and storage medium. Background Technology

[0002] Currently, with the development of automotive intelligence and the increasing demands for automotive electronic functions, the design requirements for automotive embedded controller systems are becoming increasingly stringent. During the development of automotive embedded controller systems, timely detection and localization of system anomalies, enabling developers to quickly pinpoint these issues and ensuring the development quality of the automotive embedded controller system, is a problem that needs to be solved. Summary of the Invention

[0003] This invention provides a data processing method, apparatus, device, and storage medium that can improve the efficiency and accuracy of system anomaly analysis and enhance the reliability of automotive embedded controller systems.

[0004] According to one aspect of the present invention, a data processing method is provided, comprising:

[0005] In the event of an anomaly in the system, obtain the anomaly code corresponding to the anomaly.

[0006] The exception handling method is determined based on the type of the exception code;

[0007] Using the aforementioned anomaly handling method, system anomaly information corresponding to the anomaly phenomenon is obtained;

[0008] The abnormal phenomenon is located based on the system abnormality information to obtain the system abnormality location result.

[0009] According to another aspect of the present invention, a data processing apparatus is provided, the apparatus comprising:

[0010] An anomaly code acquisition module is used to acquire the anomaly code corresponding to the anomaly when an anomaly occurs in the system.

[0011] An exception handling method determination module is used to determine the exception handling method based on the type of the exception code.

[0012] The system anomaly information acquisition module is used to acquire system anomaly information corresponding to the anomaly phenomenon using the anomaly handling method.

[0013] The anomaly localization module is used to locate the anomaly based on the system anomaly information and obtain the system anomaly localization result.

[0014] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0015] At least one processor; and

[0016] A memory communicatively connected to the at least one processor; wherein,

[0017] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the data processing method according to any embodiment of the present invention.

[0018] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the data processing method described in any embodiment of the present invention.

[0019] The technical solution of this invention, when a system anomaly occurs, obtains the anomaly code corresponding to the anomaly; determines the anomaly handling method based on the type of the anomaly code; uses the anomaly handling method to obtain the system anomaly information corresponding to the anomaly; and locates the anomaly based on the system anomaly information to obtain the system anomaly location result. This solution solves the problem that existing vehicle controller systems lack a debugging environment, making it impossible to locate system anomalies in a timely and accurate manner. It achieves the effect of timely detection and location of system anomalies during the development of automotive embedded controller systems, and allows for refined analysis and processing of the anomalies.

[0020] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 A flowchart of a data processing method provided in Embodiment 1 of the present invention;

[0023] Figure 2 This is a flowchart of a data processing method provided in Embodiment 2 of the present invention;

[0024] Figure 3 This is a flowchart of a data processing method provided in Embodiment 3 of the present invention;

[0025] Figure 4 This is a flowchart of a data processing method provided in Embodiment 4 of the present invention;

[0026] Figure 5 A flowchart of a data processing method provided in Embodiment 5 of the present invention;

[0027] Figure 6 This is a schematic diagram of the structure of a data processing device provided in Embodiment Six of the present invention;

[0028] Figure 7 This is a schematic diagram of the structure of an electronic device provided in Embodiment 7 of the present invention. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0030] It should be noted that the terms "target," "current," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "etc.", and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] Example 1

[0032] Figure 1 This document provides a flowchart of a data processing method according to Embodiment 1 of the present invention. This embodiment is applicable to situations involving data processing, particularly to situations where system anomaly information is obtained based on the anomaly code corresponding to a system anomaly phenomenon, and system anomaly location results are obtained based on the system anomaly information. This method can be executed by a data processing device, which can be implemented in hardware and / or software. This data processing device can be applied to an embedded system, which can be configured in an electronic device. Figure 1 As shown, the method includes:

[0033] S110. In the event of an abnormal phenomenon in the system, obtain the abnormal code corresponding to the abnormal phenomenon.

[0034] The system is an automotive embedded controller system. In this embodiment, the system can be an AUTOSAR (AUTOSAR: AUTomotive Open System Architecture) system. Anomalies refer to abnormal phenomena that occur during the execution of programs within the system. Optionally, in the context of automotive embedded control systems, anomalies can be categorized in various ways, specifically including three main categories of anomalies defined by the AUTOSAR system and 27 subcategories within these three categories. The three main categories of anomalies are Application Error, Protection Error, and Kernel Error.

[0035] Different types of anomalies correspond to different exception codes. The exception code is a parameter of the ErrorHook function.

[0036] It's important to note that the AUTOSAR system specifies that the controller can use ErrorHook technology to capture system anomalies. The ErrorHook function uses one byte to record the error (exception code), and defines exception codes for ApplicationError, Protection Error, and Kernel Error. AUTOSAR system vendors may further extend these exception codes to record more types of anomalies. In the AUTOSAR system, the controller can use the DetErrorHook function to enable the Det (Development Error Tracer) module. Generally, Det errors only occur during code writing, but when system anomalies exist, they may trigger a chain reaction leading to Det errors. The hook function called by the DET module is typically named Det_ErrorHook.

[0037] Specifically, the AUTOSAR system records general system information by calling the DetErrorHook function to avoid cascading anomalies during anomaly analysis and processing, thus preventing the failure to record the root cause of the problem. This general system information includes: ErrorID, coreID, and HookID. ErrorID is an identifier that can be used to characterize anomaly codes; coreID is an identifier of the kernel in the system where the anomaly occurred; and HookID is an identifier that can be used to characterize hook functions.

[0038] When the AUTOSAR system detects an anomaly in a running program, it calls a hook function to obtain and record the corresponding exception code. The hook function, or Hook function, is a technique used to intercept interactions or information exchanges between computer software components to enhance and improve the system. The parameter of the Hook function is the exception code. In ErrorHook, AUTOSAR defines three main categories and 27 subcategories of exceptions. The exception code allows the exception to be pinpointed to a specific subcategory during anomaly analysis. The exception code can include at least one of E_OS_LIMIT, E_OS_STACKFAULT, E_OS_PROTECTION_MEMORY, and E_OS_PROTECTION_EXCEPTION.

[0039] S120. Determine the exception handling method based on the type of exception code.

[0040] Different exception codes have different types. For example, exception codes include system activation exception, system stack exception, system memory protection exception, and system classification exception. If the exception code is E_OS_LIMIT, the type is determined to be a system activation exception; if the exception code is E_OS_STACKFAULT, the type is determined to be a system stack exception; if the exception code is E_OS_PROTECTION_MEMORY, the type is determined to be a system memory protection exception; and if the exception code is E_OS_PROTECTION_EXCEPTION, the type is determined to be a system classification exception. A system activation exception can be a situation where the current task is activated multiple times, or a situation where the current task needs to be activated but is not activated. A system stack exception can be a situation where the system experiences a stack overflow. When accessing data, the chip's memory protection unit has a corresponding address judgment mechanism; accessing an address without permission will result in a system memory protection exception. A system classification exception refers to a situation where the system fails to correctly classify abnormal system behavior.

[0041] Specifically, after obtaining the exception code corresponding to the anomaly, the corresponding exception analysis function is called based on the exception code. Different types of anomalies involve different information, requiring the retrieval of the ErrorID pre-stored in the AUTOSAR system, which corresponds to the exception code type. The exception handling function is then called based on the ErrorID. The exception handling method refers to the logic of using exception handling functions to process anomalies in the system.

[0042] Optionally, the chip kernel level can be determined based on the coreID. The system handles exceptions at the chip kernel level in a manner similar to interrupt response. When an exception occurs, the system can jump to the corresponding exception handling function through the exception vector table.

[0043] S130. Use exception handling methods to obtain system exception information corresponding to the abnormal phenomenon.

[0044] Specifically, since different exception types involve different information, after determining the exception code type, it is also necessary to record the exception value of the system exception corresponding to the exception code. After determining the exception handling method, an exception handling function is used to process the abnormal phenomena in the system to obtain the exception values ​​corresponding to the abnormal phenomena in the system. All obtained exception values ​​are used as system exception information.

[0045] S140. Locate the abnormal phenomenon based on the system abnormality information and obtain the system abnormality location result.

[0046] Specifically, after obtaining system anomaly information, the system determines the task, type, and address of the anomaly based on the anomaly information, and uses the task, type, and address of the anomaly as the anomaly location result.

[0047] Preferably, after obtaining the system anomaly location results, a non-volatile storage device can be used to store the system anomaly information and the system anomaly location results.

[0048] Non-volatile storage devices are storage devices that ensure data is not lost when the computer is shut down or shut down suddenly or unexpectedly.

[0049] Specifically, after obtaining the system anomaly location results, it is determined whether the anomaly involves FLASH (a memory chip) or SPI (Serial Peripheral Interface). If the anomaly involves FLASH, SPI memory is used as the non-volatile storage device to store the system anomaly information and system anomaly location results. If the anomaly involves SPI, FLASH memory is used as the non-volatile storage device to store the system anomaly information and system anomaly location results. When the system anomaly does not involve FLASH, the status of the relevant modules of FLASH, FEE (Flash EEPROM), and NvM (Non-volatile Memory) needs to be queried separately, and the main function functions of the relevant modules are cyclically scheduled to ensure that the appropriate non-volatile storage device is selected for storing the anomaly information and system anomaly location results. When the system error does not involve SPI, synchronous storage is used, polling and waiting for the external EEPROM status to be satisfied to continuously store all data. Polling is a way for the CPU to decide how to provide services to peripheral devices. The polling method involves the CPU periodically issuing queries to each peripheral device in sequence to see if it needs its services. If it does, the services are provided, and after the services are completed, the next peripheral device is queried, and so on, in an endless cycle.

[0050] Storing system anomaly information and system anomaly location results in the controller's non-volatile storage device allows developers to quickly pinpoint the cause and location of common anomalies based on the stored information, thereby rapidly optimizing the code.

[0051] The technical solution provided in this embodiment, when a system anomaly occurs, obtains the anomaly code corresponding to the anomaly; determines the anomaly handling method based on the type of the anomaly code; uses the anomaly handling method to obtain the system anomaly information corresponding to the anomaly; and locates the anomaly based on the system anomaly information to obtain the system anomaly location result. This solution solves the problem that existing vehicle controller systems lack a debugging environment, making it impossible to locate system anomalies in a timely and accurate manner. It achieves the effect of timely detection and location of system anomalies during the development of automotive embedded controller systems, and allows for refined analysis and handling of anomalies.

[0052] Based on the above embodiments, the process of locating the abnormal phenomenon according to the system abnormality information and obtaining the system abnormality location result further includes: selecting the target abnormality handling logic from the candidate abnormality handling logic; wherein, the candidate abnormality handling logic includes at least one of: ignoring the abnormality, forcibly terminating or interrupting the erroneous task, forcibly terminating the erroneous application, forcibly terminating the erroneous application and re-initializing the application, resetting the system, and shutting down the system; and using the target abnormality handling logic to process the abnormal phenomenon.

[0053] Specifically, after detecting an anomaly in the system, the target anomaly handling logic is determined from the candidate anomaly handling logics based on the anomaly handling code in the Hook.

[0054] If the exception handling logic in the Hook is determined to be to ignore the exception, the system will continue to execute subsequent tasks.

[0055] If the exception handling logic in the Hook is determined to be the forced termination or interruption of the task that has an abnormal phenomenon, since the tasks or interruptions in the AUTOSAR system are statically configured, the original system scheduling will continue after the task that has an abnormal phenomenon is forcibly terminated.

[0056] If the exception handling logic in the Hook is determined to be a forced termination of the application that is malfunctioning, then the tasks or interrupts under that application will be stopped from being scheduled.

[0057] If the exception handling logic in the Hook is determined to be to forcibly terminate the application that is malfunctioning and reinitialize the application, then the tasks or interrupts under that application will continue to be scheduled after reinitialization.

[0058] If the target exception handling logic is determined to be a system reset based on the exception handling code in the Hook, then the system is reset through a soft reset or a hard reset such as a watchdog timer.

[0059] If the target exception handling logic is determined to be shutting down the system based on the exception handling code in the Hook, then the controller enters the power-down process by shutting down the system. After the controller is powered down, the system will either be re-wake up or kept shut down depending on external conditions.

[0060] By identifying the target exception handling logic from the candidate exception handling logics and then using the target exception handling logic to handle the exception, the appropriate exception handling logic can be selected when an exception occurs in the system, thus ensuring the stability of the system.

[0061] Example 2

[0062] Figure 2This is a flowchart of a data processing method provided in Embodiment 2 of the present invention. This embodiment optimizes the above embodiment and provides a preferred embodiment where, if the exception code is E_OS_LIMIT, the exception code type is determined to be a system activation exception; the current task identifier and current task priority are obtained through the operating system state machine; and system exception information is determined based on the current task identifier, current task priority, activation exception task identifier, and activation exception task priority. Specifically, as shown... Figure 2 As shown, the method includes:

[0063] S210. In the event of an abnormal phenomenon in the system, obtain the abnormal code corresponding to the abnormal phenomenon.

[0064] S220. If the type of the exception code is system activation exception, then obtain the current task identifier and current task priority through the operating system interface.

[0065] System activation anomalies can occur when a task that requires activation is not activated, or when the same task is activated multiple times. The main causes of system activation anomalies include: a task (or interrupt) taking too long to execute, causing other tasks (or interrupts) to be activated multiple times. The operating system interface is the system interface of the operating system. This system interface is a standard API (Application Programming Interface) used to transmit task-related data within the system. The current task refers to the task currently being executed in the system; the current task identifier refers to the identification information that represents the current task.

[0066] Specifically, if the obtained exception code is E_OS_LIMIT, then the exception type is system activation exception, indicating that an activation exception exists in the system. During system scheduling, the current task identifier and current task priority can be obtained in real time through the operating system's system interface.

[0067] S230. Obtain the activation exception task identifier and activation exception task priority through the operating system state machine.

[0068] In this context, an activation anomaly task refers to a task that exhibits an activation anomaly in the system. The operating system state machine is used to record the task state of each task in the operating system in real time. The task state includes the task identifier, the task's activation status, and the task priority.

[0069] Specifically, the operating system state machine can monitor the activation information of various tasks in the system in real time. When a task with an activation anomaly is detected, a system exception message is thrown. This message includes the identifier and priority of the task with the activation anomaly. Recording these identifiers and priorities allows for precise identification of the error location. The identifier refers to the information corresponding to the task with the activation anomaly; the priority refers to the priority of the task with the activation anomaly.

[0070] S240. Determine system exception information based on the current task identifier, current task priority, activated exception task identifier, and activated exception task priority.

[0071] Specifically, first, the current task identifier and the activation abnormal task identifier are compared. If the current task identifier and the activation abnormal task identifier are the same, then the current task priority and the activation abnormal task priority are compared. If the current task priority and the activation abnormal task priority are the same, then the current task is determined to be the activation abnormal task. If the current task identifier and the activation abnormal task identifier are different, or the current task priority and the activation abnormal task priority are different, then the current task is not the activation abnormal task. In this case, it is necessary to further obtain the other task identifiers and other task priorities of other tasks in the system besides the current task identifier and the activation abnormal task through the operating system state machine.

[0072] The system determines the next task from among other tasks, compares the priorities of the current and next tasks, and identifies the next task as having an activation anomaly if the current task has a higher priority. The anomaly is caused by the current task taking too long to execute. If the current task has a lower priority than the next task (i.e., another task with a higher priority has also experienced an activation anomaly), the task experiencing the anomaly can be identified based on the activation counts of each task monitored by the system state machine. If the state machine detects an activation anomaly in the current task, it throws the current task identifier, current task priority, and anomaly cause as system anomaly information to ensure the system detects the anomaly.

[0073] S250. Locate the abnormal phenomenon based on the system abnormality information and obtain the system abnormality location result.

[0074] The technical solution of this embodiment, when a system anomaly occurs, obtains the anomaly code corresponding to the anomaly; if the anomaly code is a system activation anomaly, it obtains the current task identifier and current task priority through the operating system interface; it obtains the activation anomaly task identifier and activation anomaly task priority through the operating system state machine; based on the current task identifier, current task priority, activation anomaly task identifier, and activation anomaly task priority, it determines the system anomaly information; and based on the system anomaly information, it locates the anomaly to obtain the system anomaly location result. The above technical solution enables the determination of system anomaly information by using the current task identifier, current task priority, other task identifiers, and other task priorities obtained through the operating system state machine when a system activation anomaly occurs, thus obtaining a more accurate system anomaly location result.

[0075] Example 3

[0076] Figure 3 This is a flowchart of a data processing method provided in Embodiment 3 of the present invention. This embodiment optimizes the above embodiment and provides a preferred embodiment for determining the system exception information based on the exception code type of system stack exception. Specifically, it involves calling a stack tracking function to obtain the actual stack top address; comparing the actual stack top address with the stack design address to determine the actual number of stacks used; and determining the system exception information based on the actual number of stacks used and the stack design number. Figure 3 As shown, the method includes:

[0077] S310. In the event of an abnormal phenomenon in the system, obtain the abnormal code corresponding to the abnormal phenomenon.

[0078] S320. If the exception code type is a system stack exception, then use the stack tracking function to read the CPU stack pointer within the stack tracking function.

[0079] System stack anomalies refer to stack overflows caused by the definition of local variables within a task (or interrupt) occupying the task's (or interrupt's) stack during system scheduling. For example, the AUTOSAR system's stack protection function can detect stack overflows when the storage space below the top of the stack is modified.

[0080] It should be noted that the main causes of system stack exceptions include: the definition of local variables exceeding the system's design expectations for those local variables, or a pointer incorrectly pointing to the top of the stack, leading to an incorrect judgment of a stack overflow. Therefore, recording the task (or interrupt) identifier and the stack design number corresponding to the stack overflow can pinpoint the overflowing stack, thereby obtaining the system exception location result. However, in actual development, when analyzing system stack exceptions, it is often necessary to call the instrumentation function to determine the actual stack usage.

[0081] For example, currently, the exception handling mechanism for system stack overflow anomalies is the conventional stack protection method specified in the AUTOSAR system specification. Specifically, when the AUTOSAR system enables stack usage checking, all bytes in the stack can be filled with a specified value, and stack usage is determined by checking how many bytes below the top of the stack have not been modified. However, system stack checking has limitations. For instance, if a local variable larger than the designed stack size is defined in a system task, and some variables within that local variable are modified each time the system runs, the actual stack usage will exceed the designed stack size, causing a stack overflow. However, because the bytes below the top of the stack are not modified, the system will not report a stack overflow. Therefore, outside of the system anomaly analysis and handling process, a stack analysis method with pre-set stack tracking functions can be used to determine the actual stack usage of the task to determine whether a stack overflow has occurred.

[0082] Specifically, if the obtained exception code is E_OS_STACKFAULT, then the exception type is a system stack exception, indicating a stack overflow exception in the system. Based on the system design, identify functions with a large number of local variables within the task. Call the stack tracking function within these functions. After defining local variables, call the stack tracking function and read the CPU stack pointer within the stack tracking function to confirm the presence of a stack overflow exception in the system.

[0083] S330. Obtain the actual stack top address based on the CPU stack pointer.

[0084] The actual stack top address refers to the stack top address currently being used by the system.

[0085] Specifically, the CPU stack pointer points to the current address of the actual top of the stack. Therefore, the actual top address of the stack can be obtained based on the direction pointed to by the CPU stack pointer.

[0086] S340. Compare the actual stack top address with the stack design address to obtain the stack comparison result.

[0087] The stack design address refers to the stack address that conforms to the AUTOSAR system specification. The stack design address can be obtained from the operating system state machine. The stack design address includes the stack top address and the stack bottom address.

[0088] Specifically, the actual stack top address is compared with the stack design top address in the stack design address to obtain the stack top comparison result; the actual stack bottom address is compared with the stack design bottom address in the stack design address to obtain the stack bottom comparison result. The stack top comparison result includes the number of specified values ​​that were not modified when filled at the top of the stack; the stack bottom comparison result includes the number of specified values ​​that were not modified when filled at the bottom of the stack.

[0089] S350. Based on the stack comparison results, determine the actual number of stacks used.

[0090] Specifically, the system can calculate and determine the actual number of stacks used based on the comparison results of the top and bottom of the stack.

[0091] S360. Determine system exception information based on the actual number of stacks used and the number of stacks designed.

[0092] The stack design number refers to the number of stacks that conform to the AUTOSAR system specifications.

[0093] Specifically, if the actual number of stack elements used exceeds the designed stack size, a stack overflow is determined to exist in the system. The current task identifier, the comparison result of the stack top, and the comparison result of the stack bottom are used as system exception information.

[0094] S370. Locate the abnormal phenomenon based on the system abnormality information and obtain the system abnormality location result.

[0095] The technical solution of this embodiment, when an abnormal phenomenon occurs in the system, obtains the abnormal code corresponding to the abnormal phenomenon; if the type of the abnormal code is a system stack abnormality, then the CPU stack pointer within the stack instrumentation function is read; based on the CPU stack pointer, the actual stack top address is obtained; the actual stack top address is compared with the stack design address to obtain a stack comparison result; based on the stack comparison result, the actual number of stacks used is determined; based on the actual number of stacks used and the stack design number, system abnormality information is determined; based on the system abnormality information, the abnormal phenomenon is located to obtain a system abnormality location result. The above solution allows obtaining the actual stack top address by calling the stack instrumentation function, and obtaining the actual number of stacks used based on the actual stack top address and the stack design address. It improves the accuracy of system stack exception analysis, and can obtain more accurate system exception location results when the system exhibits stack exception anomalies.

[0096] Example 4

[0097] Figure 4 This is a flowchart of a data processing method provided in Embodiment 4 of the present invention. This embodiment optimizes the above embodiments and provides a preferred embodiment for determining the memory protection exception category through the chip memory protection unit, determining the current task identifier through the operating system interface, and determining the exception address through the CPU program pointer when the exception encoding type is a system memory protection exception. Specifically, as shown... Figure 4 As shown, the method includes:

[0098] S410. In the event of an abnormal phenomenon in the system, obtain the abnormal code corresponding to the abnormal phenomenon.

[0099] S420. If the exception code type is system memory protection exception, the memory protection exception identifier is determined through the chip memory protection unit.

[0100] Memory protection anomalies refer to memory protection errors that occur when the system accesses data but lacks the necessary access permissions to the address where the data resides. The chip memory protection unit (MPU) is a programmable area located within the memory that detects system anomalies and defines the memory's attributes and access permissions. A memory protection anomaly identifier is the task identifier corresponding to the task that experienced the memory protection anomaly.

[0101] Specifically, if the obtained exception code is E_OS_PROTECTION_MEMORY, then the exception type is a system memory protection exception, indicating that a memory protection exception exists in the system. The MPU has an address judgment mechanism. When a memory protection exception exists in the system, the exception handling method adopted is to record the memory protection exception task information that caused the memory protection exception. The memory protection exception task information may include: memory protection exception identifier, CPU program pointer, stack pointer, and CPU memory protection TRAP number. The current task information is used as system exception information.

[0102] S430: Determine the memory protection exception address through the CPU program pointer.

[0103] The memory protection exception address is the address where a memory protection exception occurs in the system.

[0104] S440. Treat the memory protection exception identifier and memory protection exception address as system exception information.

[0105] S450. Locate the abnormal phenomenon based on the system abnormality information and obtain the system abnormality location result.

[0106] The technical solution of this embodiment, when a system anomaly occurs, obtains the anomaly code corresponding to the anomaly; if the anomaly code type is a system memory protection anomaly, then the memory protection anomaly identifier is determined through the chip memory protection unit; the memory protection anomaly address is determined through the CPU program pointer; the memory protection anomaly identifier and the memory protection anomaly address are used as system anomaly information; and the anomaly is located based on the system anomaly information to obtain the system anomaly location result. Through the above solution, system anomaly information can be obtained through the chip memory protection unit, and the anomaly can be located based on the system anomaly information to obtain the system anomaly location result, thus improving the efficiency of system anomaly analysis.

[0107] Example 5

[0108] Figure 5 This is a flowchart of a data processing method provided in Embodiment 5 of the present invention. This embodiment optimizes the above embodiments and provides a preferred embodiment for determining the system anomaly information corresponding to the anomaly phenomenon based on the anomaly vector table when the anomaly coding type is system classification anomaly. Specifically, as shown... Figure 5 As shown, the method includes:

[0109] S510. In the event of an abnormal phenomenon in the system, obtain the abnormal code corresponding to the abnormal phenomenon.

[0110] S520. If the type of the anomaly code is a system classification anomaly, then the system anomaly information corresponding to the anomaly phenomenon is determined according to the anomaly vector table.

[0111] Among them, system classification anomaly refers to a situation where the system makes a classification error.

[0112] Specifically, if the obtained exception code is E_OS_PROTECTION_EXCEPTION, then the exception code type is a system-classified exception, indicating that a categorized exception exists in the system. Categorized exceptions include chip-level exceptions such as memory access errors, instruction errors, context errors, bus and peripheral device errors, etc. When a categorized exception exists in the system, the corresponding system exception information can be obtained through the exception vector table. System exception information includes the system's current task (or interrupt) identifier, the TRAP number of the chip exception, and the Class number of the chip exception.

[0113] S530. Locate the abnormal phenomenon based on the system abnormality information and obtain the system abnormality location result.

[0114] For example, the parameters and specific addresses in the system where classification anomalies occur can be located by using the CPU general-purpose register values.

[0115] The technical solution of this embodiment involves obtaining the anomaly code corresponding to the anomaly when an anomaly occurs in the system; if the anomaly code is classified as a system anomaly; determining the system anomaly information corresponding to the anomaly based on the anomaly vector table; and locating the anomaly based on the system anomaly information to obtain the system anomaly location result. This solution improves the efficiency of analyzing system anomalies by allowing the acquisition of system anomaly information from the anomaly vector table and the locating of the anomaly based on that information.

[0116] Example 6

[0117] Figure 6 This is a schematic diagram of a data processing device according to Embodiment Six of the present invention. This data processing device is applied in an embedded system. This embodiment is applicable to situations involving data processing. Figure 6 As shown, the data processing device includes: an anomaly code acquisition module 610, an anomaly handling method determination module 620, a system anomaly information acquisition module 630, and an anomaly phenomenon location module 640.

[0118] Among them, the anomaly code acquisition module 610 is used to acquire the anomaly code corresponding to the anomaly when there is an anomaly in the system.

[0119] The exception handling method determination module 620 is used to determine the exception handling method based on the type of exception code;

[0120] The system anomaly information acquisition module 630 is used to acquire system anomaly information corresponding to anomalies by using anomaly handling methods;

[0121] The anomaly location module 640 is used to locate anomalies based on system anomaly information and obtain system anomaly location results.

[0122] The technical solution provided in this embodiment, when a system anomaly occurs, obtains the anomaly code corresponding to the anomaly; determines the anomaly handling method based on the type of the anomaly code; uses the anomaly handling method to obtain the system anomaly information corresponding to the anomaly; and locates the anomaly based on the system anomaly information to obtain the system anomaly location result. This solution solves the problem that existing vehicle controller systems lack a debugging environment, making it impossible to locate system anomalies in a timely and accurate manner. It achieves the effect of timely detection and location of system anomalies during the development of automotive embedded controller systems, and allows for refined analysis and handling of anomalies.

[0123] For example, if the type of the exception code is a system activation exception, then the system exception information acquisition module 630 is specifically used for:

[0124] Obtain the current task identifier and current task priority through the operating system interface;

[0125] The system anomaly information is determined based on the current task identifier, current task priority, activated abnormal task identifier, and activated abnormal task priority.

[0126] For example, if the exception code type is a system stack exception, then the system exception information acquisition module 630 is specifically used for:

[0127] Call the stack tracking function and read the CPU stack pointer within the stack tracking function;

[0128] Obtain the actual stack top address based on the CPU stack pointer;

[0129] Compare the actual stack top address with the stack design address to obtain the stack comparison result;

[0130] Based on the stack comparison results, determine the actual number of stacks used;

[0131] Based on the actual number of stacks used and the number of stacks designed in the system, determine the system exception information.

[0132] For example, if the exception encoding type is a system memory protection exception, then the system exception information acquisition module 630 is specifically used for:

[0133] The memory protection anomaly identifier is determined by the chip memory protection unit;

[0134] The address of the memory protection exception is determined by the CPU program pointer;

[0135] The memory protection exception identifier and memory protection exception address are used as system exception information.

[0136] For example, if the type of the exception code is a system classification exception, then the system exception information acquisition module 630 is specifically used for:

[0137] The system anomaly information corresponding to the anomaly phenomenon is determined based on the anomaly vector table.

[0138] For example, the data processing apparatus described above further includes:

[0139] The target exception handling logic determination module is used to select the target exception handling logic from the candidate exception handling logics; wherein, the candidate exception handling logics include at least one of the following: ignoring the exception, forcibly terminating or interrupting the erroneous task, forcibly terminating the erroneous application, forcibly terminating the erroneous application and re-initializing the application, resetting the system, and shutting down the system;

[0140] The anomaly handling module is used to handle anomalies using the target anomaly handling logic.

[0141] Furthermore, the aforementioned data processing apparatus also includes:

[0142] The storage module is used to store system anomaly information and system anomaly location results using non-volatile storage devices.

[0143] The data processing apparatus provided in this embodiment can be applied to the data processing methods provided in any of the above embodiments, and has corresponding functions and beneficial effects.

[0144] Example 7

[0145] Figure 7 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0146] like Figure 7 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0147] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0148] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as data processing methods.

[0149] In some embodiments, the data processing method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the data processing method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the data processing method by any other suitable means (e.g., by means of firmware).

[0150] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0151] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0152] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0153] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0154] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0155] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0156] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0157] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A data processing method, characterized by, Applied to an embedded system, the method comprises: In the case of abnormal phenomena in the system, the abnormal code corresponding to the abnormal phenomenon is obtained; According to the type of the abnormal code, the abnormal processing mode is determined; The system exception information corresponding to the abnormal phenomenon is obtained by using the abnormal processing mode; According to the system exception information, the abnormal phenomenon is located to obtain the system exception positioning result; If the type of the abnormal code is system activation exception, the system exception information corresponding to the abnormal phenomenon is obtained by using the abnormal processing mode, comprising: Obtain the current task identifier and the current task priority through the operating system interface; Obtain the activation exception task identifier and the activation exception task priority through the operating system state machine; Determine the system exception information according to the current task identifier, the current task priority, the activation exception task identifier and the activation exception task priority; If the type of the abnormal code is system stack exception, the system exception information corresponding to the abnormal phenomenon is obtained by using the abnormal processing mode, comprising: Call the stack burying function to read the central processing unit (CPU) stack pointer in the stack burying function; According to the CPU stack pointer, the actual stack top address is obtained; Compare the actual stack top address with the stack design address to obtain the stack comparison result; According to the stack comparison result, the actual number of stack usage is determined; According to the actual number of stack usage and the designed number of stack, the system exception information is determined; If the type of the abnormal code is system memory protection exception, the system exception information corresponding to the abnormal phenomenon is obtained by using the abnormal processing mode, comprising: Determine the memory protection exception identifier through the chip memory protection unit; Determine the memory protection exception address through the CPU program pointer; The memory protection exception identifier and the memory protection exception address are taken as the system exception information; If the type of the abnormal code is system classification exception, the system exception information corresponding to the abnormal phenomenon is obtained by using the abnormal processing mode, comprising: According to the exception vector table, the system exception information corresponding to the abnormal phenomenon is determined.

2. The method of claim 1, wherein, In the process of locating the abnormal phenomenon according to the system exception information to obtain the system exception positioning result, it further comprises: Select the target exception handling logic from the candidate exception handling logic; Wherein, the candidate exception handling logic comprises at least one of the following: ignore exception, forcibly terminate or interrupt the task with error, forcibly terminate the application with error, forcibly terminate the application with error and reinitialize the application, reset the system and shut down the system; The target exception handling logic is used to handle the abnormal phenomenon.

3. The method of claim 1, wherein, Comprise: The system exception information and the system exception positioning result are stored by using the non-volatile storage device.

4. A data processing apparatus, characterized by, Applied to an embedded system, the device comprises: Abnormal code acquisition module, used for obtaining the abnormal code corresponding to the abnormal phenomenon in the case of abnormal phenomena in the system; Abnormal processing mode determination module, used for determining the abnormal processing mode according to the type of the abnormal code; The system exception information acquisition module is configured to acquire system exception information corresponding to the abnormal phenomenon according to the abnormal processing mode. The abnormal phenomenon positioning module is configured to position the abnormal phenomenon according to the system exception information, and obtain a system exception positioning result. If the type of the exception code is a system activation exception, the system exception information acquisition module is specifically configured to: acquire a current task identifier and a current task priority through an operating system interface; acquire an activation exception task identifier and an activation exception task priority through an operating system state machine; determine system exception information according to the current task identifier, the current task priority, the activation exception task identifier, and the activation exception task priority. If the type of the exception code is a system stack exception, the system exception information acquisition module is specifically configured to: call a stack burying function to read a central processing unit (CPU) stack pointer in the stack burying function; acquire an actual stack top address according to the CPU stack pointer; compare the actual stack top address with a stack design address to obtain a stack comparison result; determine a stack actual usage number according to the stack comparison result; determine system exception information according to the stack actual usage number and a stack design number. If the type of the exception code is a system memory protection exception, the system exception information acquisition module is specifically configured to: determine a memory protection exception identifier through a chip memory protection unit; determine a memory protection exception address through a CPU program pointer; determine the memory protection exception identifier and the memory protection exception address as system exception information. If the type of the exception code is a system classification exception, the system exception information acquisition module is specifically configured to: determine system exception information corresponding to the abnormal phenomenon according to an exception vector table.

5. An electronic device, comprising: The electronic device includes: at least one processor; and a memory connected with the at least one processor in communication; wherein the memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the data processing method in any one of claims 1-3.

6. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions for enabling the processor to implement the data processing method in any one of claims 1-3 when executed.

Images