Abnormality processing method and device, equipment and storage medium

Abstract

The invention provides an exception handling method and device, equipment and a storage medium, and aims to solve the problems that the exception of embedded equipment is difficult to locate and the operation and maintenance operation is complicated, and the method comprises the steps: obtaining an exception interrupt signal generated in the operation process of the embedded equipment; in response to the exception interrupt signal, extracting call stack information when an exception occurs, and executing self-defined exception handling function analysis on the call stack information to obtain a current exception function address; according to an instruction pointer register value in the current abnormal function address and a base address pointer register value in a stack pointer position in the call stack information, backtracking traversal is carried out, a function call chain relation is constructed, and structured abnormal information is generated; performing priority grading processing on the structured exception information, and writing the structured exception information into a corresponding partition of the storage device according to a priority grading result; and in response to a maintainable command input by a user, reading the structured exception information stored in the corresponding partition from the storage device.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to an exception handling method, apparatus, device, and storage medium. Background Technology

[0002] Embedded devices, with their small size, low power consumption, and high reliability, are widely used in key fields such as industrial control, IoT terminals, and smart hardware. These devices typically operate in complex and harsh environments, making them susceptible to malfunctions caused by software logic errors and external interference. If these malfunctions are not located and handled accurately and promptly, they can lead to device downtime, data loss, or even cascading failures, severely impacting system stability and operational efficiency. Therefore, malfunction handling technology is a core support for ensuring the reliable operation of embedded devices.

[0003] Currently, anomaly handling in embedded devices mainly relies on traditional debugging methods and basic log storage solutions. However, these methods have many shortcomings in practical applications, making it difficult to meet the needs of efficient fault diagnosis and operation and maintenance management. For example, anomaly information capture depends on external debugging interfaces, which lacks stability; moreover, the efficiency of fault root cause location is low, and the resource utilization rate is low when storing anomaly data. Summary of the Invention

[0004] In view of this, the present disclosure provides an anomaly handling method, apparatus, device and storage medium to solve the pain points of difficult anomaly location, easy loss of core data and complex operation and maintenance of embedded devices, improve the efficiency of fault diagnosis, reduce maintenance costs, and at the same time ensure data reliability and operation and maintenance convenience.

[0005] In a first aspect, an exception handling method is provided, comprising: acquiring an exception interrupt signal generated during the operation of an embedded device; in response to the exception interrupt signal, extracting call stack information at the time of the exception, and parsing the call stack information using a custom exception handling function to obtain the address of the current exception function; the call stack information including the stack pointer position; performing backtracking traversal and constructing a function call chain relationship based on the instruction pointer register value in the current exception function address and the base address pointer register value in the stack pointer position to generate structured exception information; performing priority classification processing on the structured exception information, and writing the structured exception information into the corresponding partition of a storage device according to the priority classification result; and in response to a maintainable command input by a user, reading the structured exception information stored in the corresponding partition from the storage device.

[0006] In one implementation, before parsing the call stack information using a custom exception handling function, the following exception handling interrupt is performed: in response to the exception interrupt signal, the default exception handling function is replaced with a custom exception handling function through an exception vector table redirection mechanism, the custom exception handling function being used to parse the call stack information; the interrupt type code of the exception interrupt signal is obtained, the corresponding exception category is queried according to the interrupt type code mapping table, and an exception type identifier is determined, the exception type identifier being used as reference information for priority-based processing of the structured exception information; and / or, the system clock counter value at the time of the exception occurrence is read, the system clock counter value being used for exception sequence analysis.

[0007] In one embodiment, the method further includes: detecting the current count value of the watchdog timer and calculating the remaining reset time; determining whether the remaining reset time is less than a preset minimum exception handling duration threshold based on the remaining reset time; if it is less than the minimum exception handling duration threshold, writing a delay instruction to the watchdog timer to extend the watchdog reset time to n times the minimum exception handling duration threshold, where n≥1.

[0008] In one implementation, parsing the call stack information using a custom exception handling function includes: based on the call stack information, reading register values ​​from the general-purpose register group and the special register group in the custom exception handling function to generate register snapshot data; filtering the register snapshot data according to preset data cleaning rules, the preset data cleaning rules including removing duplicate stack pointer values, removing register data with uninitialized flags set to true, and removing register data with values ​​in a preset invalid mode to obtain valid register state data; extracting the instruction pointer register value from the valid register state data, and using the instruction pointer register value as a memory address to perform a symbol table lookup to obtain the address of the current exception function.

[0009] In one implementation, the backtracking traversal and construction of the function call chain relationship includes: taking the current abnormal function address as the starting node of the function call chain; extracting the base pointer register value from the stack frame corresponding to the current abnormal function address; locating the base address position of the previous stack frame based on the base pointer register value; reading the previous base pointer value and return address from the base address position to obtain the previous called function information; performing an iterative backtracking operation on the previous called function information, repeating the process of extracting the base pointer value and return address until the extracted base pointer value is zero or the backtracking depth reaches the preset maximum call chain length, thereby generating the function call chain relationship.

[0010] In one implementation, the method further includes: based on the function call chain relationship, counting the total number of function nodes in the function call chain relationship to obtain a call chain depth value; based on the call chain depth value, determining whether the call chain depth value exceeds a preset maximum safe call depth threshold; if it exceeds, adding a call stack overflow risk label to the structured exception information to generate the function call chain relationship with the risk label.

[0011] In one implementation, after parsing the call stack information using a custom exception handling function, register status data is also obtained. Generating structured exception information includes: mapping fields according to a preset data structure template based on the exception triggering function indicated by the current exception function address, the function call chain relationship, and the register status data to generate a basic exception information structure; obtaining system operating parameters at the time of the exception, including CPU utilization, memory usage, task queue length, and interrupt nesting level; formatting the system operating parameters to generate system status snapshot data; and structurally encapsulating the basic exception information structure and the system status snapshot data, adding data integrity check codes and version identifier fields to generate the structured exception information.

[0012] In one implementation, prioritizing the structured anomaly information includes: extracting anomaly type identifiers and system state snapshot data based on the structured anomaly information; generating multidimensional anomaly features based on the anomaly type identifiers and system state snapshot data; quantifying and evaluating the multidimensional anomaly features using a preset multi-level scoring rule, wherein the multi-level scoring rule includes anomaly type base score, system resource impact weight, and historical fault frequency coefficient, to obtain a quantitative severity index; and comparing the quantitative severity index with a preset grading threshold range to determine the priority grading result.

[0013] In one implementation, writing the structured anomaly information into the corresponding partition of the storage device according to the processed priority classification result includes: partitioning the storage device according to a preset capacity ratio based on the total capacity of the storage device; the partition includes an emergency storage area, a regular storage area, and a cache storage area; the anomaly data stored in the emergency storage area has a higher priority than the anomaly data stored in the regular storage area; the cache storage area is used to temporarily store anomaly data in the emergency storage area and the regular storage area that has not been synchronized to the cloud; setting a power failure priority protection flag for the emergency storage area, configuring a power monitoring trigger mechanism for write operations to ensure that the anomaly data matching the emergency storage area is written before power failure; configuring a cyclic overwrite strategy for the regular storage area and the cache storage area, setting a preset data retention period for the regular storage area, and setting a network status linkage clearing mechanism for the cache storage area to complete the partitioning strategy configuration.

[0014] In one implementation, the priority classification result divides the structured anomaly information into critical anomaly data, severe anomaly data, general anomaly data, and minor anomaly data. The step of writing the structured anomaly information into the corresponding partition of the storage device according to the processed priority classification result further includes: querying the partition address mapping table of the storage device to obtain the starting address of the emergency storage area corresponding to the critical anomaly data, obtaining the secondary address of the emergency storage area corresponding to the severe anomaly data, and obtaining the addresses of the regular storage areas corresponding to the general and minor anomaly data; performing a data compression algorithm on the structured anomaly information to generate compressed anomaly information; writing the compressed anomaly information into the corresponding storage area address according to the first-in, first-out principle; when the remaining space in the emergency storage area or the regular storage area is less than the size of a single anomaly information data entry, overwriting the data in the emergency storage area before a preset storage duration or the earliest written data in the regular storage area, thus completing the persistent storage of the structured anomaly information.

[0015] Secondly, an anomaly handling device is provided, comprising: The acquisition module is used to acquire abnormal interrupt signals generated during the operation of the embedded device. An exception interruption handling module is used to respond to the exception interruption signal, extract the call stack information at the time of the exception, and execute a custom exception handling function to parse the call stack information to obtain the address of the current exception function; the call stack information includes the stack pointer position; The structured exception information generation module is used to perform backtracking and construct function call chain relationships based on the instruction pointer register value in the current exception function address and the base address pointer register value in the stack pointer position, and generate structured exception information. The partition writing module is used to perform priority classification processing on the structured abnormal information, and write the structured abnormal information into the corresponding partition of the storage device according to the priority classification result. A read module is used to read the structured exception information stored in the corresponding partition from the storage device in response to a maintainable command input by the user.

[0016] Thirdly, an electronic device is provided, including a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and the processor is configured to execute the machine-readable instructions stored in the memory, wherein when the machine-readable instructions are executed by the processor, the processor performs the steps of the exception handling method described in any of the above embodiments.

[0017] Fourthly, a computer-readable storage medium is provided, including instructions stored thereon, wherein, when the instructions are executed by a processor, the exception handling method described in any of the above embodiments is executed.

[0018] The exception handling method provided in this disclosure intercepts abnormal interrupt signals generated during device operation and directly parses call stack information based on a custom exception handling function. It does not rely on external debugging interfaces and can reliably capture core exception data even after device encapsulation and deployment or under complex operating conditions. Furthermore, it does not consume additional system resources, avoiding the impact of real-time monitoring on device performance and power consumption, and eliminating the security risks associated with open debugging interfaces. In addition, this disclosure constructs a complete function call chain and generates structured exception information through backtracking of instruction pointer register values ​​and base address pointer register values. Developers can intuitively reconstruct the complete execution path of the exception through this structured information, quickly pinpointing the source function and associated call levels that triggered the exception, eliminating the need to search through massive amounts of unordered data. This significantly shortens the location cycle and reduces the difficulty of troubleshooting, especially for faults that occur infrequently and are difficult to reproduce. Furthermore, this disclosure prioritizes and processes the structured exception information and writes it to the corresponding partition of the storage device. Partitioned storage enables differentiated allocation of storage resources, preventing redundant data from occupying limited storage space for extended periods and balancing data reliability with storage resource utilization. Afterwards, by responding to the maintainable commands input by the user, the structured anomaly information of the corresponding partition can be read. No professional debugging tools and complicated operation procedures are required, which greatly improves the on-site operation and maintenance response speed, reduces human resource consumption and on-site maintenance costs, avoids long-term system and service interruptions for users, and improves user experience and satisfaction. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating an exemplary embodiment of the present disclosure of an exception handling method; Figure 2 This disclosure illustrates an exemplary embodiment of an exception handling apparatus. Figure 3 This is a schematic diagram of a computer device illustrated in an exemplary embodiment of this disclosure. Detailed Implementation

[0020] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0021] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0022] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0023] Furthermore, the symbol “ / ” in this disclosure indicates that there is an “or” relationship between the related objects before and after the symbol, or that the related objects have an exemplary relationship that can coexist.

[0024] like Figure 1 The diagram shown is a flowchart of an exception handling method provided in an embodiment of this disclosure, including: S101: Obtain abnormal interrupt signals generated during the operation of the embedded device.

[0025] Here, when an embedded device is running, an exception will occur (such as hardware failure, software logic error, memory out of bounds, etc.). The system will issue a corresponding exception interrupt signal. This step captures the signal in real time through the hardware interrupt mechanism or system interface to confirm that the exception has occurred.

[0026] S102: In response to the abnormal interrupt signal, extract the call stack information when the abnormality occurred, and execute a custom abnormality handling function to parse the call stack information to obtain the address of the current abnormal function; the call stack information includes the stack pointer position.

[0027] Here, upon receiving an exception interrupt signal, the call stack information (including the stack pointer position and the memory address trace of function execution) at the moment the exception occurred is extracted. This information is then parsed through a custom exception handling function (which replaces the system default function) to determine the address of the current exception function, i.e., the location identifier of the function that directly caused the exception in memory.

[0028] The call stack information may specifically include the program pointer position (its value always points to the address of the currently executing instruction in memory), the stack pointer position (its value always points to the top of the call stack (the latest allocated address of the stack memory)), the original data of user general-purpose registers (general-purpose containers in the CPU used for temporary storage of data, instruction parameters and calculation results), and the original data of special registers (dedicated registers in the CPU with specific functions, not used for general data storage, but responsible for recording the core context such as CPU running status and stack frame association information).

[0029] When executing a custom exception handling function, in addition to obtaining the address of the current exception function, register state data used to locate the exception trigger point and restore the execution context can also be obtained. This register state data is a complete snapshot of the CPU registers at the moment the exception occurs, including user general-purpose register data and special-purpose register data. User general-purpose register data stores temporary data, input parameters, and calculation results during function execution, reflecting the function's operational state at the time of the exception. Special-purpose register data stores key information such as CPU operating mode, stack frame association, and exception identifiers (e.g., base pointer (BP), program status register (PSR), stack pointer (SP), etc.), reflecting the system context at the time of the exception.

[0030] Here, the user general-purpose register data and special-purpose register data in the register status data are structured and valid data formed after parsing, cleaning, and formatting the original register data in the call stack information.

[0031] In one implementation, before parsing the call stack information using a custom exception handling function, the following exception handling interruption process is further performed: in response to the exception interruption signal, the default exception handling function is replaced with a custom exception handling function through an exception vector table redirection mechanism, the custom exception handling function being used to parse the call stack information; the interrupt type code of the exception interruption signal is obtained, the corresponding exception category is queried according to the interrupt type code mapping table, and an exception type identifier is determined, the exception type identifier being used as reference information for priority-based processing of the structured exception information; and / or, the system clock counter value at the time of the exception occurrence is read, the system clock counter value being used for exception sequence analysis.

[0032] Here, when an exception occurs in an embedded device, the system will execute the default exception handling function by default (which usually only performs simple reset and log printing, and cannot meet the need for accurate capture of exception information). By redirecting the exception vector table and replacing the exception handling function, it can be ensured that when an exception occurs, a custom function that can capture and parse exception information is executed, rather than the system's default simple handling function.

[0033] In addition, the unique numerical code assigned to each exception by the CPU or system (e.g., 0x03 for memory out-of-bounds error, 0x08 for hardware overheating, 0x12 for arithmetic overflow, etc.) serves as the underlying identifier to distinguish exception types. The interrupt type encoding mapping table is a pre-defined encoding-exception category correspondence table (e.g., 0x03 - fatal memory error, 0x08 - severe hardware failure, 0x12 - general software exception), used to translate the underlying encoding into exception categories that can be used for hierarchical classification. The exception type identifier is the final generated structured label (e.g., fatal level - memory out-of-bounds error, general level - arithmetic overflow), which directly serves as the core reference for subsequent priority classification. After an exception interrupt signal is triggered, the interrupt type code carried in the signal is read first, and then the corresponding exception category is queried through the pre-defined encoding mapping table to finally generate an exception type identifier (e.g., severe level - hardware failure) and temporarily store it. In subsequent steps, the structured exception information needs to be written to different Flash partitions according to the severity of the exception (e.g., fatal level written to the emergency area, general level written to the regular area). At this time, the severity of the exception can be determined based on the exception type identifier, thereby achieving hierarchical storage.

[0034] The system clock counter is a high-precision timer at the hardware level of embedded devices (driven by the CPU or a dedicated clock chip). It records the number of clock cycles (usually in nanoseconds) from system startup to the current time. Unaffected by software lag or system load, it is more accurate than the system time at the software level. When multiple anomalies occur within a short period, comparing the clock counter values ​​of each anomaly can determine the order in which they occurred (e.g., if the counter value for anomaly A is 123456 and that for anomaly B is 123789, then A occurred before B), helping to analyze whether there is a chain reaction where one anomaly triggers another. At the instant an anomaly interrupt is triggered, the current value of the system clock counter is immediately read and temporarily stored. This value can then be used to generate a high-precision timestamp and incorporate structured anomaly information.

[0035] In one implementation, to avoid interruption of the exception handling process due to device reset triggered by watchdog timer timeout, and to ensure the integrity of exception information capture, parsing, and storage, this disclosure also provides a method for dynamic adaptation of watchdog reset time. Specifically, the current count value of the watchdog timer is detected, and the remaining reset time is calculated. Based on the remaining reset time, it is determined whether the remaining reset time is less than a preset minimum exception handling duration threshold. If it is less than the minimum exception handling duration threshold, a delay instruction is written to the watchdog timer to extend the watchdog reset time to n times the minimum exception handling duration threshold, where n≥1.

[0036] Here, the watchdog timer of the embedded device is a hardware component to prevent system freezes. It continuously counts down (the count value decreases). If a "feed the watchdog" instruction is not written before the countdown ends, the timer will force a device reset to restore system operation. However, exception handling (such as parsing the call stack and storing structured information) requires a certain amount of time. If the remaining reset time is insufficient, the processing flow will be interrupted and exception information will be lost. Therefore, in this embodiment of the present disclosure, after an exception interruption is triggered, the current count value of the watchdog timer is read first. Combined with the timer's counting frequency, the remaining reset time before device reset is calculated. The remaining reset time is compared with a preset minimum exception handling duration threshold (i.e., the shortest time required to complete exception information parsing and storage). If the remaining reset time is less than the threshold (indicating that the current time is insufficient to complete exception handling), a delay instruction is written to the watchdog timer to extend the reset time to n times the threshold (n≥1), ensuring that the exception handling function can be executed completely. This avoids incomplete exception information capture and storage failure due to watchdog timeout reset, ensuring the integrity of the data required for subsequent fault location.

[0037] In one implementation, to remove invalid, redundant, and abnormal data from the call stack information and ensure the accuracy of subsequent exception function location, the parsing process of the call stack information by the custom exception handling function can include complete logic of register data capture, multi-dimensional cleaning and filtering, and target address extraction. Specifically, the parsing of the call stack information by the custom exception handling function includes: based on the call stack information, reading the register values ​​of the general-purpose register group and the special register group in the custom exception handling function to generate register snapshot data; filtering the register snapshot data according to preset data cleaning rules, which include removing duplicate stack pointer values, removing register data with uninitialized flags set to true, and removing register data with values ​​in a preset invalid mode to obtain valid register state data; extracting the instruction pointer register value from the valid register state data, and using the instruction pointer register value as a memory address to perform a symbol table lookup to obtain the address of the current exception function.

[0038] Here, the preset data cleaning rules include, for example,: calculating the difference between stack pointer values ​​between adjacent stack frames based on the register snapshot data to obtain a stack frame size sequence; performing statistical analysis on the stack frame size sequence to calculate the median and standard deviation of the stack frame size; marking stack frames whose size exceeds the range of the median plus or minus 3 times the standard deviation as abnormal stack frames; and deleting the register data corresponding to the abnormal stack frames from the valid register state data.

[0039] Specifically, after the parsing process begins, the custom exception handling function reads the real-time values ​​of the CPU's general-purpose register set (which stores function parameters, computation data, etc.) and special register set (which stores stack frame associations, CPU state, etc.) from the call stack information, generating register snapshot data. By completely preserving the original register state at the moment the exception occurs, comprehensive raw material can be provided for subsequent analysis, avoiding the loss of critical context.

[0040] To address potential redundancy, invalidity, and anomaly interference in the original snapshot data, a dual cleaning mechanism is employed. The first step is basic cleaning: directly removing duplicate stack pointer values ​​(to avoid data redundancy), uninitialized register data (meaningless random values), and data with preset invalid patterns (such as fixed invalid codes), quickly filtering out obviously useless information. The second step involves adding anomaly stack frame filtering rules: identifying anomalous stack frames through statistical analysis. First, the difference in stack pointer values ​​between adjacent stack frames (i.e., the size of a single stack frame) is calculated to form a stack frame size sequence. Then, a normal range is constructed using the median and three times the standard deviation (median ± three times the standard deviation; this statistical method effectively resists extreme value interference). Stack frames exceeding this range are marked as anomalous (potentially invalid stack frames caused by stack overflow, data tampering, etc.), and their corresponding register data is deleted. After this dual cleaning, valid register state data is finally obtained, eliminating redundancy and anomaly interference. Extract the value of the instruction pointer register from the cleaned valid register status data. This value is essentially the memory address of the instruction being executed when the exception occurred. Use this address as an index to look up the system symbol table (a mapping table between memory addresses and function names) to directly obtain the function corresponding to that address, which is the address of the current exception function.

[0041] S103: Based on the instruction pointer register value in the current exception function address and the base pointer register value in the stack pointer position, perform backtracking traversal and construct the function call chain relationship to generate structured exception information.

[0042] Here, the instruction pointer register value at the current exception function address (to locate the specific instruction when the exception occurred) is used, combined with the base pointer register value at the stack pointer position (to trace the memory location of the previous function), to backtrack through all called functions layer by layer and construct a complete function call chain (such as A→B→C→exception function); then, information such as exception function address, call chain, and register status is integrated to generate structured exception information in a unified format (to avoid data clutter).

[0043] In one implementation, to reconstruct the function call path at the time of the exception and accurately trace the source of the fault propagation, a complete function call chain can be constructed by backtracking stack frames, providing a clear link for subsequent root cause analysis. The specific implementation is as follows: The current exception function address is used as the starting node of the function call chain; the call chain data structure is initialized to obtain the initial call chain node; the base pointer register value is extracted from the stack frame corresponding to the current exception function address; the base address position of the preceding stack frame is located based on the base pointer register value; the preceding base pointer value and return address are read from the base address position to obtain the preceding function call information; an iterative backtracking operation is performed on the preceding function call information, repeating the process of extracting the base pointer value and return address until the extracted base pointer value is zero or the backtracking depth reaches the preset maximum call chain length, thus generating the function call chain relationship.

[0044] Here, the address of the current exception function obtained from previous parsing is used as the starting node of the function call chain (i.e., the function directly triggered by the exception). Simultaneously, the call chain data structure (such as a linked list or array) is initialized, storing the address of the exception function and related register information into the structure to form the initial call chain node, laying the foundation for subsequent backtracking. During a function call, an independent stack frame is created in the memory stack, storing key information such as the base address pointer (BP register value) and return address. The base address pointer is the core link connecting the stack frame of the previous function. The operation logic is as follows: extract the base address pointer register value from the stack frame corresponding to the current exception function; use this value to locate the preceding stack frame (i.e., the stack frame of the function calling the current exception function); then read the preceding base address pointer value (used to continue tracing to the next higher-level function) and the return address (mapped to the specific information of the preceding called function) from this preceding stack frame, ultimately obtaining the information of the preceding called function. The iterative operation of extracting the base address pointer value, locating the previous stack frame, and reading the previous base address pointer value and return address is repeatedly performed on the information of the preceding function call until either of the following termination conditions is met: the extracted base address pointer value is 0 (indicating that the program has been traced back to the top-level entry function); or the backtracking depth reaches the preset maximum call chain length (to avoid infinite backtracking due to stack data anomalies). After iteration, all traced functions are organized in the order of top-level entry function → intermediate call functions → current exception function, forming a complete function call chain relationship.

[0045] In one implementation, the risk of stack overflow can be made explicit by detecting the safety boundary of the function call chain depth, thereby providing accurate clues for anomaly root cause analysis. Specifically, based on the function call chain relationship, the total number of function nodes in the function call chain relationship can be counted to obtain the call chain depth value; according to the call chain depth value, it can be determined whether the call chain depth value exceeds a preset maximum safe call depth threshold. If it exceeds, a call stack overflow risk label is added to the structured anomaly information to generate the function call chain relationship with the risk label.

[0046] Here, call stack overflow risk tags are added to the structured exception information, transforming the originally hidden layer risks into explicit structured identifiers and generating function call chains with risk tags. By making implicit risks explicit, developers no longer need to analyze the call hierarchy one by one; they can directly focus on the fatal root cause of stack overflow through tags, skipping tedious layer-by-layer investigation and further improving the efficiency of exception localization.

[0047] In practical implementation, when generating structured anomaly information, the core anomaly link information and system operating environment data can be integrated to form a standardized data carrier that is standardized, complete, and directly usable for fault analysis. Specifically, based on the anomaly triggering function indicated by the current anomaly function address, the function call chain relationship, and the register status data, field mapping is performed according to a preset data structure template to generate a basic anomaly information structure; system operating parameters at the time of the anomaly are obtained, including CPU utilization, memory usage, task queue length, and interrupt nesting level, and the system operating parameters are formatted to generate system status snapshot data; the basic anomaly information structure and the system status snapshot data are structurally encapsulated, and data integrity check codes and version identifier fields are added to generate the structured anomaly information. In this way, by integrating link data and environmental data, it is clear what the anomaly is, how it propagates, and under what system state the anomaly occurs, thus providing a panoramic basis for subsequent root cause analysis.

[0048] In some cases, abnormal hardware environments can also cause device malfunctions. Therefore, in other embodiments of this disclosure, hardware environment parameters can be monitored and faults can be determined. For example, when the abnormal handling interrupt is received, the temperature sensor data and voltage monitoring module data of the embedded device are read to obtain hardware environment parameters; a threshold judgment is performed on the hardware environment parameters to determine whether the temperature value is greater than a preset temperature (e.g., 85 degrees Celsius) or whether the voltage fluctuation rate is greater than a set ratio (e.g., ±10%), to obtain a hardware abnormality determination result; when the hardware abnormality determination result is true, a suspected hardware fault tag is added to the structured abnormality information, and the specific values ​​of the hardware environment parameters are recorded to generate the structured abnormality information with hardware diagnostic information. Furthermore, based on the hardware environment parameters in the multiple structured anomaly information stored in history, a dynamic learning algorithm can be performed on the temperature threshold and voltage fluctuation threshold to calculate the mean and standard deviation of the environment parameters and generate adaptive threshold parameters. Outlier removal processing is performed on the adaptive threshold parameters, and extreme values ​​are filtered using the 3-sigma criterion before recalculating the threshold to obtain an optimized judgment threshold. The optimized judgment threshold is then updated to the threshold register of the hardware anomaly judgment module to achieve adaptive optimization of hardware fault judgment.

[0049] S104: Prioritize the structured anomaly information and write it into the corresponding partition of the storage device according to the priority classification result.

[0050] Here, structured anomaly information is divided into different priorities (such as critical, severe, general, and minor) according to preset rules (such as severity and scope of impact); data is written to the corresponding partition of the storage device (such as flash memory) according to priority (high priority is written to the emergency area of ​​power failure protection, and low priority is written to the regular area) to avoid core fault data being overwritten by low-value data.

[0051] In one implementation, prioritizing the structured anomaly information may include: extracting anomaly type identifiers and system state snapshot data based on the structured anomaly information; generating multidimensional anomaly features based on the anomaly type identifiers and system state snapshot data; quantitatively evaluating the multidimensional anomaly features using preset multi-level scoring rules, the multi-level scoring rules including anomaly type base score, system resource impact weight, and historical fault frequency coefficient, to obtain a quantitative severity index; and comparing the quantitative severity index with a preset grading threshold range to determine the priority grading result.

[0052] Here, for example, data with a comprehensive severity score of 90 or higher are classified as critically ill anomalous data, data with a comprehensive severity score between 70 and 90 are classified as severely ill anomalous data, data with a comprehensive severity score between 40 and 70 are classified as moderately ill anomalous data, and data with a comprehensive severity score less than 40 are classified as slightly ill anomalous data.

[0053] From structured anomaly information, two core features can be extracted: anomaly type identifiers (such as memory overflow and excessively high hardware temperature, reflecting the inherent severity of the anomaly) and system state snapshot data (such as high CPU usage and memory overflow, reflecting the scope of the anomaly's impact on the system). These are combined to form multidimensional anomaly features. A preset multi-level scoring rule is applied to score these multidimensional anomaly features. The scoring dimension includes three parts: a base score for the anomaly type (e.g., a base score of 80 for a fatal fault and 30 for a minor warning); a weighting for the impact on system resources (e.g., a weighting of 1.2 times for an anomaly causing CPU usage to exceed 90%, and 0.8 times for a minor impact); and a historical fault frequency coefficient (e.g., adding 5-10 points for a high frequency of device restarts caused by this type of anomaly). These three factors are combined to obtain a quantitative severity index (i.e., a comprehensive score). The system presets a grading threshold range and classifies levels based on a comprehensive score. For example, ≥90 points is considered critical, 70-90 points is considered severe, 40-70 points is considered moderate, and <40 points is considered minor. The final output is a clear priority grading result. This implementation achieves accurate grading through multi-dimensional comprehensive scoring; simultaneously, the priority results directly connect to subsequent partitioned storage logic (critical / severe cases are stored in the emergency area, moderate / minor cases are stored in the regular area), ensuring that high-priority anomalies receive priority protection and processing. This approach adapts to the limited resources of embedded devices, improving the targeting and efficiency of fault diagnosis.

[0054] In practical implementation, to adapt to the storage needs of abnormal data with different priorities, optimize storage resource allocation, and ensure that critical data is not lost and unsynchronized data is traceable, a strategy of partitioning and differentiated storage can be configured to achieve accurate and secure storage of structured abnormal information. Specifically, based on the total capacity of the storage devices, partitions are created according to a preset capacity ratio; the partitions include an emergency storage area, a regular storage area, and a cache storage area; the abnormal data stored in the emergency storage area has a higher priority than the abnormal data stored in the regular storage area, and the cache storage area is used to temporarily store abnormal data in the emergency storage area and the regular storage area that has not been synchronized to the cloud; a power failure priority protection flag is set for the emergency storage area, and a power monitoring trigger mechanism for write operations is configured to ensure that the abnormal data matching the emergency storage area is written before power failure; a cyclic overwrite strategy is configured for the regular storage area and the cache storage area, a preset data retention period is set for the regular storage area, and a network status linkage clearing mechanism is set for the cache storage area, thus completing the partitioning strategy configuration.

[0055] Here, the emergency storage area stores high-priority critical / serious anomaly data, while the regular storage area stores low-priority general / minor anomaly data, with the emergency storage area having a higher priority than the regular storage area. The cache area stores temporary copies of anomaly data in the emergency and regular storage areas that have not been synchronized to the cloud. The three areas have a subordinate relationship of original storage and temporary storage. The cache area does not store independently generated new data; it only serves as a transit point for unsynchronized data from the first two areas. It is automatically cleared after synchronization to the cloud and does not affect the retention of the original data.

[0056] The preset capacity allocation can be, for example, 20% of the total capacity for emergency storage, 30% for regular storage, and 50% for cache storage, to complete partition initialization.

[0057] The network status linkage clearing mechanism means that the clearing action of the cache is bound to the network connection status of the embedded device. The cache is only automatically cleared when the device is connected to the network and all abnormal data in the cache that has not been synchronized to the cloud is successfully uploaded; when the network is disconnected, the data is retained to avoid the loss of unsynchronized data.

[0058] Here, for high-priority data (such as fatal fault information) stored in the emergency storage area, a core protection mechanism is configured: a power-loss priority protection flag is set to clearly indicate that the data in this partition is non-lossable due to power failure; a power monitoring trigger mechanism for write operations is configured to monitor the device's power supply status in real time. If a power failure signal is detected, priority is given to ensuring the completion of data writing in the emergency storage area, preventing the loss of high-priority abnormal data due to sudden power failure. For the regular storage area, a cyclic overwrite strategy is configured, along with a preset data retention period (e.g., 1 month). When partition space is insufficient, the earliest data exceeding the retention period is overwritten according to the first-in-first-out principle, ensuring the traceability of low-priority data while preventing storage resource exhaustion. For the cache storage area, a network status-linked clearing mechanism is configured. Its clearing action is bound to the device's network connection status. Unsynchronized data is retained when the network is disconnected to prevent data loss; the cache area is automatically cleared only when the device is connected to the network and all unsynchronized data in the cache area has been successfully uploaded to the cloud, ensuring the integrity of data synchronization without affecting the original data in the emergency and regular areas. This implementation method can simultaneously meet the needs of secure storage and efficient utilization of data with different priorities.

[0059] In practical implementation, cloud and local storage can be collaboratively performed. For example, the network connection status of an embedded device can be detected to determine whether the device is connected to the Internet and obtain a network status identifier. When the network status identifier indicates that the device is connected to the Internet, the structured abnormal information with the unsynchronized flag bit set to true is read from the emergency storage area and the regular storage area, an upload data packet is constructed, and a dataset to be synchronized is generated. Based on the dataset to be synchronized, the dataset to be synchronized is uploaded to the cloud server through a Hypertext Transfer Protocol Secure (HTTPS) encrypted channel. After successful upload, the unsynchronized flag bit of the corresponding data is modified to false, completing the cloud-based collaborative storage.

[0060] Here, when constructing the upload data packet, the frequency statistics of each anomaly type can be calculated based on the structured anomaly information in the emergency storage area and the regular storage area, and a frequency statistics report can be generated. An anomaly detection algorithm is executed on the frequency statistics report to identify anomaly types whose frequency growth rate exceeds a set ratio (50%), and the anomaly types are marked as high-frequency anomalies to obtain high-frequency anomaly identifiers. The high-frequency anomaly identifiers are appended to the corresponding structured anomaly information, and a priority upload flag is added to the upload data packet to ensure that the structured anomaly information of the high-frequency anomalies is synchronized to the cloud first.

[0061] For example, the priority classification result divides the structured anomaly information into critical anomaly data, severe anomaly data, general anomaly data, and minor anomaly data; the step of writing the structured anomaly information into the corresponding partition of the storage device according to the processed priority classification result further includes: querying the partition address mapping table of the storage device to obtain the starting address of the emergency storage area corresponding to the critical anomaly data, obtaining the secondary address of the emergency storage area corresponding to the severe anomaly data, and obtaining the addresses of the regular storage areas corresponding to the general anomaly data and the minor anomaly data; performing a data compression algorithm on the structured anomaly information to generate compressed anomaly information; writing the compressed anomaly information into the corresponding storage area address according to the first-in-first-out principle; when the remaining space of the emergency storage area or the regular storage area is less than the size of a single anomaly information data, overwriting the data in the emergency storage area before the preset storage time or the earliest written data in the regular storage area, thus completing the persistent storage of the structured anomaly information.

[0062] Here, by querying the partition address mapping table of the storage device (which records the correspondence between partitions and physical addresses), precise binding between abnormal data and storage addresses is achieved: critical abnormal data corresponds to the starting address of the emergency storage area (core storage bit, prioritized for writing); severe abnormal data corresponds to the secondary address of the emergency storage area (secondary core bit within the emergency area, stored in the same partition as critical data to avoid confusion); general and minor abnormal data uniformly correspond to the addresses of the regular storage area (sharing regular storage resources according to priority). Furthermore, a lossless data compression algorithm (such as the LZ77 algorithm) is performed on the structured abnormal information to compress the structured data containing information such as call chains, register states, and system snapshots, generating compressed abnormal information. This reduces the storage space occupied by a single abnormal data entry, adapts to the limited storage resources of embedded devices, increases the amount of data that can be stored in the storage partition without compromising data integrity, and extends the cycle overwrite period. Furthermore, a First-In-First-Out (FIFO) principle is adopted to write compressed abnormal data to the corresponding target address, ensuring the temporal consistency of data storage (new data does not overwrite old data that has not yet expired). When the remaining space in the emergency storage area or the regular storage area is less than the size of a single abnormal data entry, a cyclic overwrite mechanism is activated: the emergency storage area prioritizes overwriting data older than the preset storage duration (such as critical / serious data from 3 months ago, ensuring the retention of recent high-priority data); the regular storage area directly overwrites the earliest written data (meeting the short-term traceability needs of general / minor data). This avoids the inability to write new data due to storage resource exhaustion, and balances the long-term retention of high-priority data with the reasonable turnover of low-priority data through differentiated overwrite rules.

[0063] In one implementation, to optimize the data turnover logic of the regular storage area and avoid accidental deletion of recently valid low-priority abnormal data, the aforementioned cyclic overwrite strategy can achieve intelligent overwrite through time-sensitive tag management, thereby further improving storage resource utilization and data retention rationality. Specifically, the cyclic overwrite strategy further includes: based on the write operations of the regular storage area, attaching a write timestamp and validity period identifier to each abnormal information data to generate abnormal information data with time-sensitive tags; before executing a new write operation, scanning the validity period identifiers of all abnormal information data in the regular storage area, marking data whose difference between the current time and the write timestamp exceeds one month as expired data, and obtaining an expired data list; based on the expired data list, prioritizing the overwrite of data blocks in the expired data list, and only overwriting the earliest written valid data when there is no expired data, thus completing intelligent cyclic overwrite.

[0064] In this way, when abnormal data is written to the regular storage area, a write timestamp and expiration date identifier are appended to each data entry, generating abnormal data with an expiration date tag. Before writing new data, all data in the regular storage area is scanned, and data with a difference of more than one month between the current time and the write timestamp is marked as expired data, forming an expired data list. Data blocks in the expired data list are overwritten first, and only when there is no expired data are the oldest valid data written in sequence, completing intelligent cyclic overwriting. This avoids the premature overwriting of recently valid data and ensures the continuous availability of storage space.

[0065] S105: In response to a maintainable command input by the user, read the structured exception information stored in the corresponding partition from the storage device.

[0066] Here, when a user inputs a preset maintainable command (such as querying anomalies of a specific priority or time period), the system can respond to the command, locate the corresponding partition address in the storage device, read the structured anomaly information, and return it to the user, achieving rapid fault tracing without the need for professional debugging tools.

[0067] To facilitate users' quick and accurate retrieval of target anomaly information, this disclosure provides a structured anomaly information query process based on maintainable commands, ensuring efficient querying and reliable data. Specifically, based on the maintainable command input by the user, the anomaly query parameters in the maintainable command are parsed. These anomaly query parameters include anomaly type filtering conditions, time range limits, and priority filtering conditions, generating a query condition set. According to the query condition set, a condition matching operation is performed in the partition index table of the Flash storage device to locate the storage address of the anomaly information data that meets the conditions, obtaining a target data address list. Based on the target data address list, the compressed data at the corresponding address is read sequentially, and decompression and data integrity verification are performed to obtain the structured anomaly information.

[0068] Here, after the user inputs a maintainable command, the exception type filtering conditions, time range limits, and priority filtering conditions contained in the command are extracted to generate a standardized set of query conditions. Based on the set of query conditions, a matching operation is performed in the partition index table of the Flash storage device to accurately locate the storage address of the exception information that meets the conditions, forming a target data address list. The compressed exception data is read sequentially according to the target data address list, decompression is performed, and integrity verification is conducted to ensure that the data has not been tampered with or damaged, ultimately obtaining complete structured exception information.

[0069] Based on the storage and query of the aforementioned anomaly information, the root cause of the anomaly can be accurately located. In specific implementation, a hierarchical mechanism of local priority derivation, dynamic updating of the rule base, and cloud collaborative supplementation can be adopted to form a complete anomaly root cause analysis system.

[0070] For example, based on the structured anomaly information, the anomaly type identifier and the function call chain relationship are extracted to construct an anomaly feature pattern and generate a feature vector to be matched; a pattern matching operation is performed on the feature vector to be matched in the local rule base, which may contain a target number of (e.g., 100) or more predefined anomaly-root cause mapping rules to obtain preliminary root cause inference results; when the confidence of the preliminary root cause inference results is greater than a set confidence threshold (e.g., 80%), the preliminary root cause inference results are used as the final root cause conclusion and added to the anomaly diagnosis report to complete the local root cause inference.

[0071] In one implementation, when a rule base update message pushed by the cloud server is detected, incremental rule package data can be downloaded to obtain a new rule set; local rule compatibility verification is performed on the new rule set to check the matching degree between the rule condition field and the local abnormal feature field, and a verified rule set is generated; the verified rule set is merged into the local rule base, and low-frequency rules that have not been hit for more than a set period (6 months) are deleted to complete the automatic update of the rule base.

[0072] Furthermore, when the local rule base fails to match a root cause, the feature vector to be matched is uploaded to the cloud-based root cause inference service via an encrypted channel, initiating a cloud-based collaborative inference request. Based on the cloud-based historical fault case database, cosine similarity calculation is performed on the feature vector to be matched, and historical cases with similarity greater than or equal to a set similarity threshold (e.g., 80%) are retrieved to obtain a candidate root cause list. The candidate root cause list is then weighted and sorted, and a comprehensive recommendation score is calculated based on the frequency of case occurrence and the matching degree of device model. The root cause with the highest score is selected as the cloud-based inference conclusion, generating a cloud-based root cause recommendation result and returning it to the embedded device.

[0073] In implementation, based on the aforementioned anomaly information storage and query technologies, early fault prediction and risk prevention can be achieved. For example, a two-layer early warning mechanism can be constructed, combining local real-time monitoring and early warning with cloud-based intelligent model prediction. For instance, based on the structured anomaly information stored locally on the embedded device for the past m days (e.g., 7 days), the daily occurrence frequency of each anomaly type can be statistically analyzed to generate an anomaly frequency time series. The month-on-month growth rate of the anomaly frequency time series can be calculated, and anomaly types with a month-on-month growth rate exceeding a set proportion (e.g., 50%) can be identified to obtain high-risk anomaly type identifiers. When a high-risk anomaly type identifier exists, a high-risk early warning message is generated, which may include the high-risk anomaly type identifier, current frequency, and growth trend data. This early warning notification is sent through a local alarm interface or a cloud push channel to complete local fault early warning. For example, based on historical anomaly data from multiple devices aggregated on a cloud server, the data is grouped according to device model and deployment region to generate a grouped training dataset. Temporal features are extracted from the grouped training dataset, including the frequency of anomaly occurrence, the distribution of anomaly types, and the fluctuation values ​​of environmental parameters, to construct a multi-dimensional temporal feature matrix and obtain a training feature set. Based on the training feature set, a Long Short-Term Memory Network (LSTM) model is used for training, with the probability of anomaly restart in a preset number of days (e.g., 7 days) as the prediction target. The model parameters are optimized through the backpropagation algorithm to generate a fault prediction model. The fault prediction model is used to perform inference calculations on the real-time uploaded device anomaly data. When the predicted probability of anomaly restart in a preset number of days is greater than the preset probability (40%), an early warning message is generated and pushed to maintenance personnel 24 hours in advance of the preset number of days, realizing cloud-based fault prediction.

[0074] like Figure 2 As shown, this embodiment of the disclosure provides an exception handling device 200, including: The acquisition module 21 is used to acquire abnormal interrupt signals generated during the operation of the embedded device; The exception interruption handling module 22 is used to respond to the exception interruption signal, extract the call stack information at the time of the exception, and execute a custom exception handling function to parse the call stack information to obtain the address of the current exception function; the call stack information includes the stack pointer position; The structured exception information generation module 23 is used to perform backtracking and construct function call chain relationships based on the instruction pointer register value in the current exception function address and the base address pointer register value in the stack pointer position, and generate structured exception information. The partition writing module 24 is used to perform priority classification processing on the structured abnormal information, and write the structured abnormal information into the corresponding partition of the storage device according to the priority classification result. The reading module 25 is used to read the structured exception information stored in the corresponding partition from the storage device in response to a maintainable command input by the user.

[0075] The specific implementation process of the functions and roles of each unit in the above-mentioned device can be found in the implementation process of the corresponding steps in the above-mentioned exception handling method, and will not be repeated here.

[0076] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this disclosure according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0077] Based on the same technical concept, this disclosure also provides an electronic device 300, referring to... Figure 3 The diagram shown is a schematic representation of the structure of an electronic device according to an exemplary embodiment of this disclosure, comprising: The processor 310, memory 320, and bus 330 are included. The memory 320 is used to store execution instructions and includes main memory 321 and external memory 322. The main memory 321, also known as internal memory, is used to temporarily store the operation data in the processor 310 and the data exchanged with external memory 322 such as hard disk. The processor 310 exchanges data with external memory 322 through main memory 321.

[0078] In this embodiment of the present disclosure, the memory 320 is specifically used to store application code that executes the scheme of the present disclosure, and its execution is controlled by the processor 310. That is, when the electronic device 300 is running, the processor 310 communicates with the memory 320 through the bus 330, or the processor 310 communicates with the memory 320 through other means, so that the processor 310 executes the application code stored in the memory 320, and then executes the steps of the exception handling method described in any of the foregoing embodiments.

[0079] The memory 320 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0080] Processor 310 may be an integrated circuit chip with signal processing capabilities. The aforementioned processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor.

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

[0082] This disclosure also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the image display method described in the above-described method embodiments. The storage medium may be a volatile or non-volatile computer-readable storage medium.

[0083] This disclosure also provides a computer program product storing a computer program. When the computer program is run by a processor, it executes the steps of the exception handling method provided in any of the above embodiments of this disclosure. For details, please refer to the above method embodiments, which will not be repeated here.

[0084] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium, which can be a volatile or non-volatile computer-readable storage medium. In another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0085] Furthermore, embodiments of the subject matter and functional operation described in this specification can be implemented in the following ways: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or combinations thereof. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory program carrier for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. Alternatively or additionally, program instructions may be encoded on artificially generated propagation signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information and transmit it to a suitable receiving device for execution by the data processing apparatus. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or combinations thereof.

[0086] The processing and logic flows described in this specification can be executed by one or more programmable computers that execute one or more computer programs to perform corresponding functions by operating on input data and generating output. The processing and logic flows can also be executed by dedicated logic circuits—such as field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs), and the device can also be implemented as dedicated logic circuits.

[0087] Suitable computers for executing computer programs include, for example, general-purpose and / or special-purpose microprocessors, or any other type of central processing unit. Typically, the central processing unit receives instructions and data from read-only memory and / or random access memory. The basic components of a computer include a central processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as disks, magneto-optical disks, or optical disks, or the computer will be operatively coupled to such mass storage devices to receive data from or transfer data to them, or both. However, a computer is not required to have such devices. Furthermore, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device such as a Universal Serial Bus (USB) flash drive, to name a few.

[0088] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. Processors and memory may be supplemented by or incorporated into dedicated logic circuitry.

[0089] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily intended to describe features of specific embodiments of a particular invention. Certain features described in the various embodiments herein may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in various embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation thereof.

[0090] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or requiring all illustrated operations to be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0091] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings are not necessarily shown in a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0092] The above description is merely a preferred embodiment of this disclosure and is not intended to limit this disclosure. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. An exception handling method, characterized in that, include: Acquire abnormal interrupt signals generated during the operation of the embedded device; In response to the abnormal interruption signal, the call stack information at the time of the abnormality is extracted, and a custom abnormality handling function is executed to parse the call stack information to obtain the address of the current abnormal function; the call stack information includes the stack pointer position; Based on the instruction pointer register value at the current abnormal function address and the base pointer register value at the stack pointer position, backtracking is performed to construct the function call chain relationship and generate structured exception information; The structured anomaly information is prioritized and then written into the corresponding partition of the storage device according to the priority ranking result. In response to a maintainable command input by the user, the structured exception information stored in the corresponding partition is read from the storage device.

2. The method according to claim 1, characterized in that, Before parsing the custom exception handling function on the call stack information, the following exception handling interrupt is also performed: In response to the abnormal interruption signal, the default exception handling function is replaced with a custom exception handling function through the exception vector table redirection mechanism. The custom exception handling function is used to parse the call stack information. Obtain the interrupt type code of the abnormal interrupt signal, query the corresponding abnormal category according to the interrupt type code mapping table, and determine the abnormal type identifier. The abnormal type identifier is used as reference information for priority classification processing of the structured abnormal information; and / or, read the system clock counter value at the time of the abnormality, and the system clock counter value is used for abnormal sequence analysis.

3. The method according to claim 1 or 2, characterized in that, The method further includes: Detect the current count value of the watchdog timer and calculate the remaining reset time; Based on the remaining reset time, determine whether the remaining reset time is less than a preset minimum exception handling duration threshold. If it is less than the minimum exception handling duration threshold, write a delay instruction to the watchdog timer to extend the watchdog reset time to n times the minimum exception handling duration threshold, where n≥1.

4. The method according to claim 1, characterized in that, The process of parsing the call stack information using a custom exception handling function includes: Based on the call stack information, the register values ​​of the general-purpose register group and the special register group are read in the custom exception handling function to generate register snapshot data; The register snapshot data is filtered according to a preset data cleaning rule, which includes removing duplicate stack pointer values, removing register data with an uninitialized flag set to true, and removing register data with values ​​in a preset invalid mode, to obtain valid register state data. Extract the instruction pointer register value from the valid register status data, use the instruction pointer register value as a memory address to perform a symbol table lookup, and obtain the address of the current exception function.

5. The method according to claim 1, characterized in that, The process of backtracking and constructing the function call chain includes: The current abnormal function address is used as the starting node of the function call chain. The base address pointer register value is extracted from the stack frame corresponding to the current abnormal function address. The base address position of the previous stack frame is located according to the base address pointer register value. The previous base address pointer value and return address are read from the base address position to obtain the previous called function information. An iterative backtracking operation is performed on the preceding function call information, repeatedly extracting the base address pointer value and return address until the extracted base address pointer value is zero or the backtracking depth reaches the preset maximum call chain length, thereby generating the function call chain relationship.

6. The method according to claim 5, characterized in that, Also includes: Based on the function call chain relationship, the total number of function nodes in the function call chain relationship is counted to obtain the call chain depth value; Based on the call chain depth value, determine whether the call chain depth value exceeds the preset maximum safe call depth threshold. If it does, add a call stack overflow risk label to the structured exception information and generate the function call chain relationship with the risk label.

7. The method according to claim 1, characterized in that, After parsing the call stack information using a custom exception handling function, register status data is also obtained; the generation of structured exception information includes: Based on the exception triggering function indicated by the current exception function address, the function call chain relationship, and the register status data, field mapping is performed according to a preset data structure template to generate a basic exception information structure. Obtain system operating parameters at the time of the anomaly, including CPU utilization, memory usage, task queue length, and interrupt nesting level; format the system operating parameters to generate system status snapshot data. The basic anomaly information structure and the system state snapshot data are encapsulated in a structured manner, and data integrity check code and version identifier fields are added to generate the structured anomaly information.

8. The method according to claim 1, characterized in that, The structured anomaly information is processed by prioritization, including: Based on the structured anomaly information, anomaly type identifiers and system state snapshot data are extracted, and multidimensional anomaly features are generated based on the anomaly type identifiers and system state snapshot data. The multidimensional anomaly features are quantitatively evaluated using a preset multi-level scoring rule, which includes anomaly type base score, system resource impact weight, and historical fault frequency coefficient, to obtain a quantitative severity index. The quantified severity index is compared with a preset grading threshold range to determine the priority grading result.

9. The method according to claim 8, characterized in that, The step of writing the structured exception information into the corresponding partition of the storage device according to the processed priority classification result includes: Based on the total capacity of the storage devices, the storage is divided into partitions according to a preset capacity ratio. The partitions include an emergency storage area, a regular storage area, and a cache storage area. The abnormal data stored in the emergency storage area has a higher priority than the abnormal data stored in the regular storage area. The cache storage area is used to temporarily store abnormal data in the emergency storage area and the regular storage area that has not been synchronized to the cloud. A power failure priority protection flag is set for the emergency storage area, and a power monitoring trigger mechanism for write operations is configured to ensure that abnormal data matching the emergency storage area is written before power failure. Configure a cyclic overwrite policy for the regular storage area and the cache storage area, set a preset data retention period for the regular storage area, and set a network status-linked clearing mechanism for the cache storage area to complete the partitioning policy configuration.

10. The method according to claim 9, characterized in that, The priority classification result divides the structured anomaly information into critical anomaly data, severe anomaly data, general anomaly data, and minor anomaly data; The step of writing the structured exception information into the corresponding partition of the storage device according to the processed priority classification result further includes: Query the partition address mapping table of the storage device to obtain the starting address of the emergency storage area corresponding to the fatal abnormal data, obtain the secondary address of the emergency storage area corresponding to the severe abnormal data, and obtain the addresses of the regular storage areas corresponding to the general abnormal data and the minor abnormal data. A data compression algorithm is applied to the structured anomaly information to generate compressed anomaly information; The compressed abnormal information is written to the corresponding storage area address according to the first-in-first-out principle. When the remaining space in the emergency storage area or the regular storage area is less than the size of a single abnormal information data, the data in the emergency storage area before the preset storage time or the earliest data written in the regular storage area is overwritten to complete the persistent storage of the structured abnormal information.

11. An anomaly handling device, characterized in that, include: The acquisition module is used to acquire abnormal interrupt signals generated during the operation of the embedded device. An exception interruption handling module is used to respond to the exception interruption signal, extract the call stack information at the time of the exception, and execute a custom exception handling function to parse the call stack information to obtain the address of the current exception function; the call stack information includes the stack pointer position; The structured exception information generation module is used to perform backtracking and construct function call chain relationships based on the instruction pointer register value in the current exception function address and the base address pointer register value in the stack pointer position, and generate structured exception information. The partition writing module is used to perform priority classification processing on the structured abnormal information, and write the structured abnormal information into the corresponding partition of the storage device according to the priority classification result. A read module is used to read the structured exception information stored in the corresponding partition from the storage device in response to a maintainable command input by the user.

12. An electronic device, characterized in that, The system includes a processor and a memory, the memory storing machine-readable instructions executable by the processor, the processor executing the machine-readable instructions stored in the memory, and when the machine-readable instructions are executed by the processor, the processor performing the steps of the exception handling method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, Includes instructions stored thereon, wherein, when the instructions are executed by the processor, the exception handling method as described in any one of claims 1-10 is executed.

Images