CN116430835B - Fault storage and analysis method of Cortex-M microcontroller - Google Patents
Fault storage and analysis method of Cortex-M microcontroller Download PDFInfo
- Publication number
- CN116430835B CN116430835B CN202310695106.7A CN202310695106A CN116430835B CN 116430835 B CN116430835 B CN 116430835B CN 202310695106 A CN202310695106 A CN 202310695106A CN 116430835 B CN116430835 B CN 116430835B
- Authority
- CN
- China
- Prior art keywords
- fault
- microcontroller
- data
- cortex
- register
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000004458 analytical method Methods 0.000 title claims abstract description 11
- 238000012795 verification Methods 0.000 claims abstract description 12
- 238000012546 transfer Methods 0.000 claims abstract description 7
- 230000002159 abnormal effect Effects 0.000 claims description 36
- 230000005856 abnormality Effects 0.000 claims description 15
- 230000006870 function Effects 0.000 claims description 8
- 238000000034 method Methods 0.000 claims description 8
- 238000012545 processing Methods 0.000 claims description 4
- 238000005457 optimization Methods 0.000 description 6
- 238000003745 diagnosis Methods 0.000 description 4
- 238000011161 development Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B23/00—Testing or monitoring of control systems or parts thereof
- G05B23/02—Electric testing or monitoring
- G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
- G05B23/0208—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the configuration of the monitoring system
- G05B23/0213—Modular or universal configuration of the monitoring system, e.g. monitoring system having modules that may be combined to build monitoring program; monitoring system that can be applied to legacy systems; adaptable monitoring system; using different communication protocols
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/24—Pc safety
- G05B2219/24065—Real time diagnostics
Landscapes
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Automation & Control Theory (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention belongs to a fault storage and analysis method of a Cortex-M microcontroller in the technical field of an automobile electronic embedded real-time system, which comprises the steps of calling an exception handling routine to collect fault data when the microcontroller breaks down to trigger an exception interrupt, storing the fault data into a non-initialized RAM space, executing information verification on the fault data after the microcontroller executes system software reset and initialization, calling a Dem module to transfer the fault data which is completed to be verified into the RAM space of the Dem module, and storing the fault data which is completed to be verified into a non-volatile memory after the non-initialized RAM space is cleared; the invention can quickly locate assembly sentences in fault and related modules for causing the fault of the microcontroller by directionally collecting the data related to the fault of the microcontroller and combining the debugger and the field file containing debugging information, and can quickly and effectively analyze the cause of the fault of the microcontroller.
Description
Technical Field
The invention belongs to the technical field of automobile electronic embedded real-time systems, and particularly relates to a fault storage and analysis method of a Cortex-M microcontroller.
Background
AUTOSAR, collectively Automotive Open System Architecture, i.e., the automobile open system architecture. The system is a collaborative development framework of an automobile electronic system which is participated by all automobile manufacturers, spare part suppliers and various research and service institutions together worldwide, and an open automobile controller (ECU) standard software architecture is established; the Cortex-M microcontroller in the automobile ECU under the AUTOSAR architecture comprises a Dem module for confirming the occurrence of faults, wherein the Dem module is used for collecting fault status bytes and fault diagnosis snapshot data by the diagnosis event management module, and the Dem module calls an NvM module (nonvolatile storage module) to request to store the fault diagnosis snapshot data.
In the prior art, an automobile ECU is based on an embedded system scheme, and when a fault of a core of a Cortex-M microcontroller is encountered, such as abnormal running of a program, program crash and the like, the fault cannot be recorded normally, and the fault cannot be positioned effectively; the method is concretely characterized in the following two aspects:
(1) When the core of the Cortex-M microcontroller fails, modules such as Dem\NvM and the like cannot be operated normally, so that the failure cannot be recorded normally;
(2) After the core of the Cortex-M microcontroller fails, the system crashes, then the watchdog is reset, the system is restarted, and the context information of the failure site is lost, if the core fails to be repeated, the failure cannot be effectively positioned.
Disclosure of Invention
The invention aims to provide a fault storage and analysis method of a Cortex-M microcontroller, so as to solve the problems in the background technology.
The invention realizes the above purpose through the following technical scheme:
a fault storage and analysis method of a Cortex-M microcontroller comprises the following steps:
s1: when the Cortex-M microcontroller generates fault triggering abnormal interrupt, the Cortex-M microcontroller actively calls a preset abnormal processing routine to directionally collect fault data, and the fault data is stored in a non-initialized RAM space in the Cortex-M microcontroller;
the fault data comprises an abnormal number, stack space data before the CPU enters an abnormality and register data in a fault state;
s2: executing system software reset and initialization by the Cortex-M microcontroller, executing information verification on the fault data in the non-initialized RAM space after the initialization is completed, calling a dem_SetEventStatus function in the Dem module by the Cortex-M microcontroller to transfer the fault data which is completed in verification into the RAM space of the Dem module, and calling an NvM_WriteBlock function by the Dem module to store the fault data which is completed in verification into a nonvolatile memory after the non-initialized RAM space is cleared;
s3: and loading an elt file in the fault data through a debugger to start a debugging interface, analyzing a PC register value in stack space data before a CPU enters an exception in the debugging interface, positioning an assembly statement of the Cortex-M microcontroller before the CPU enters the exception, reversely deducing a final assembly, manually inputting the values of the PC register, the LR register, the R12 register, the R3 register, the R2 register, the R1 register and the R0 register according to the final assembly statement to restore context data of the Cortex-M microcontroller in fault, and reversely deducing the fault cause of the Cortex-M microcontroller by combining the exception number and the register data in fault state.
As a further optimization scheme of the invention, the abnormal interrupts in the step S1 comprise internal bus abnormal interrupts, memory management abnormal interrupts, usage abnormal interrupts and hard abnormal interrupts of the Cortex-M microcontroller.
As a further optimization scheme of the invention, when fault data in the step S1 are stored in the non-initialized RAM space, the Cortex-M microcontroller outputs abnormal fault data of the Cortex-M microcontroller to an external platform through a CAN bus CAN_ID (0 x 00).
As a further optimization of the present invention, the exception handling routine in step S1 includes: and actively collecting the fault data by the Cortex-M microcontroller, juxtaposing a 'microcontroller fault flag bit' in the Cortex-M microcontroller as effective, and storing the fault data into a non-initialized RAM space after CRC32 check information is added in the fault data.
As a further optimization scheme of the invention, in step S2, after the initialization of the Cortex-M microcontroller is completed, the information verification process is as follows:
s2.1: performing CRC32 check information check on fault data in the non-initialized RAM space to judge whether the fault data is complete, and executing step S2.2 if the judging result is complete;
s2.2: judging whether a 'microcontroller fault zone bit' in the non-initialized RAM space is effective, and if the judging result is effective, calling a Dem module to transfer fault data.
As a further optimization scheme of the invention, in the Cortex-M microcontroller, the anomaly numbers in the directionally collected fault data and the fault types corresponding to the anomaly numbers comprise:
number 3 corresponds to a hard failure; number 4 corresponds to a memory management failure; number 5 corresponds to an internal bus fault; number 6 corresponds to the usage failure.
As a further optimization scheme of the invention, in the Cortex-M microcontroller, the corresponding relation between the register data and the abnormal number in the fault state in the fault data is as follows:
if the anomaly number is 3, the data of a hard fault state register is required to be extracted, the register address is 0xE000_ED2C, and the effective length is 32 bits;
if the anomaly number is 4, the data of a 'memory management fault state register' needs to be extracted, and the register address is 0xE000_ED28, and the effective length is 8 bits;
if the anomaly number is 5, the data of 'internal bus fault' needs to be extracted, the register address is 0xE000_ED29, and the effective length is 8 bits;
the exception number is 6, the data of 'usage failure' needs to be extracted, the register address is 0xE000_ED2A, and the effective length is 9 bits.
The invention has the beneficial effects that:
the invention realizes that when the automobile ECU breaks down and crashes due to the failure of the microcontroller, the data related to the failure of the microcontroller can still be recorded;
the invention can quickly locate assembly sentences in fault and related modules for causing the fault of the microcontroller by directionally collecting the data related to the fault of the microcontroller and combining a debugger and an elf file containing debugging information, thereby quickly and effectively analyzing the cause of the fault of the microcontroller;
in the invention, when the fault abnormal interrupt of the microcontroller is entered, the data related to the fault of the microcontroller is stored in the non-initialized RAM, and the corresponding data is stored after the reset, thereby solving the problem that the fault data cannot be normally stored when the microcontroller crashes and crashes;
in the invention, related data of the Cortex-M microcontroller during faults comprise abnormal numbers, stack space data before a CPU enters an abnormality and data of a fault state register corresponding to the corresponding abnormality, and the data are very effective for analyzing the reasons of the faults of the microcontroller;
in the invention, the relevant data of the Cortex-M microcontroller in fault is combined with the debugger and the field file comprising debugging information, so that the real cause of the microcontroller fault can be quickly and effectively positioned when the scene in fault is quickly restored.
Drawings
Fig. 1 is an overall flow diagram of the present invention.
Detailed Description
The invention will now be described in further detail with reference to the accompanying drawings, wherein it is to be understood that the following detailed description is for the purpose of illustration only and is not to be construed as limiting the scope of the invention, as various insubstantial modifications and adaptations of the invention to those skilled in the art may be made in light of the foregoing disclosure.
Example 1
As shown in fig. 1, the invention provides a fault storage and analysis method of a Cortex-M microcontroller, which comprises the following steps:
s1: when the Cortex-M microcontroller generates fault triggering abnormal interrupt, the Cortex-M microcontroller actively calls a preset abnormal processing routine to directionally collect fault data, and the fault data is stored in a non-initialized RAM space in the Cortex-M microcontroller;
the fault data comprise an abnormal number, stack space data before the CPU enters an abnormality and register data in a fault state.
S2: executing system software reset and initialization by the Cortex-M microcontroller, executing information verification on the fault data in the non-initialized RAM space after the initialization is completed, calling a dem_SetEventStatus function in the Dem module by the Cortex-M microcontroller to transfer the fault data which is completed in verification into the RAM space of the Dem module, and calling an NvM_WriteBlock function by the Dem module to store the fault data which is completed in verification into a nonvolatile memory after the non-initialized RAM space is cleared;
the system comprises a diagnostic event management module, a Dem module and a Cortex-M microcontroller, wherein the Dem module is used for collecting fault status bytes and fault diagnosis snapshot data, a Ram space of the Dem module is used for storing diagnostic events (errors) and related data, and a non-initialized RAM space of the Cortex-M microcontroller is used for storing flash data in the Cortex-M microcontroller.
S3: and loading an elf file in the fault data through a debugger to start a debugging interface, analyzing a PC register value in stack space data before a CPU enters an exception in the debugging interface, positioning an assembly statement before the CPU enters the exception interrupt and reversely deducing a final assembly statement, manually inputting the values of the PC register, the LR register, the R12 register, the R3 register, the R2 register, the R1 register and the R0 register according to the final assembly statement to restore the context data of the context-M microcontroller when the fault occurs, and reversely deducing the fault reason of the context-M microcontroller by combining the exception number and the register data under the fault state.
Further, core faults of the Cortex-M microcontroller can be classified into internal bus faults, memory management faults, usage faults and hard faults; the internal bus fault mainly refers to errors occurring during data access, finger access, stacking and unstacking; memory management failures are mainly illegal accesses made against memory protection requirements; the usage failure mainly refers to that the kernel tries to use an illegal assembly instruction; hard failures are mainly internal bus failures, memory management failures, and usage failures.
When the core fault occurs in the Cortex-M microcontroller in the automobile ECU, the storage process for the fault information comprises the following steps: when the automobile ECU has kernel faults, system kernel abnormal interrupts (internal bus fault abnormal interrupts, memory management fault abnormal interrupts, usage fault abnormal interrupts and hard fault abnormal interrupts) are triggered, and an abnormal processing routine is called in the abnormal interrupts.
Further, the exception handling routine in step S1 includes: the Cortex-M microcontroller actively collects fault data, and the microcontroller fault flag bit in the Cortex-M microcontroller is set to be effective, and the fault data is stored into the non-initialized RAM space after CRC32 check information is added in the fault data.
In the context-M microcontroller exception handling routine, the program actively collects exception numbers, stack space data before the CPU enters an exception, register data in a fault state and the like in a directed manner, sets a 'microcontroller fault flag bit' as valid, adds check information of CRC32, and stores all the data into a 'non-initialized RAM space'.
The microcontroller exception handling routine calls Cortex-M microcontroller software reset when ending, the Cortex-M microcontroller is reset and then reinitialized, after initialization is finished, the non-initialized RAM space is checked, the CRC32 check is firstly performed to confirm the integrity and consistency of data, and then whether the microcontroller fault flag bit is valid is checked
If the 'microcontroller fault flag bit' is valid, the system calls a dem_seteventstatus function in the Dem module, and the fault data of the 'non-initialized RAM space' is transferred to the RAM space of the Dem module, and the 'non-initialized RAM space' is cleared.
The Dem module further invokes an nvm_writeblock function to store the failure data in the nonvolatile storage medium.
Further, while the fault data in step S1 is stored in the non-initialized RAM space, the Cortex-M microcontroller outputs abnormal fault data of the Cortex-M microcontroller to the external platform through the CAN bus can_id (0 x 00).
Further, in step S2, after initializing the Cortex-M microcontroller, the information checking process is:
s2.1: performing CRC32 check information check on fault data in the non-initialized RAM space to judge whether the fault data is complete, and executing step S2.2 if the judging result is complete;
s2.2: judging whether a 'microcontroller fault zone bit' in the non-initialized RAM space is effective, and if the judging result is effective, calling a Dem module to transfer fault data.
Further, in the Cortex-M microcontroller, the anomaly number and the corresponding fault type in the directionally collected fault data comprise:
number 3 corresponds to a hard failure; number 4 corresponds to a memory management failure; number 5 corresponds to an internal bus fault; number 6 corresponds to the usage failure.
It should be noted that how to locate core abnormality of Cortex-M microcontroller, there is no generally effective method at present, and aiming at the above-mentioned defects, the technical solution of the present invention combines with special architecture of Cortex-M to describe specific fault data when microcontroller abnormality should be extracted, and when core abnormality occurs, there is a large amount of context information, the present invention selects the most critical and effective core data of Cortex-M, which has a certain representativeness and higher fault location accuracy.
Specifically, after the Cortex-M microcontroller is abnormally interrupted, context data before the abnormality is input needs to be reversely pushed out through the stack pointer SP when the abnormality routine is input, and corresponding extraction is performed. Including an xPSR register value, a PC register value, an LR register value, an R12 register value, an R3 register value, an R2 register value, an R1 register value, and an R0 register value before entering an abort.
Further, in the Cortex-M microcontroller, the corresponding relation between the register data and the abnormal number in the fault state in the fault data is as follows:
if the anomaly number is 3, the data of a hard fault state register is required to be extracted, the register address is 0xE000_ED2C, and the effective length is 32 bits;
if the anomaly number is 4, the data of a 'memory management fault state register' needs to be extracted, and the register address is 0xE000_ED28, and the effective length is 8 bits;
if the anomaly number is 5, the data of 'internal bus fault' needs to be extracted, the register address is 0xE000_ED29, and the effective length is 8 bits;
the exception number is 6, the data of 'usage failure' needs to be extracted, the register address is 0xE000_ED2A, and the effective length is 9 bits.
The fault analysis method for the microcontroller specifically comprises the following steps:
and the field file is used for analyzing the cause of the fault of the microcontroller.
And reading related data when the microcontroller fails by a diagnostic instrument.
And loading the elf file by the debugger, and starting a debugging interface.
And analyzing the PC register value in the data of the stack space before the CPU enters the exception, and positioning the last assembly statement before the Cortex-M microcontroller enters the microcontroller and is aborted.
And positioning the last assembly statement before entering the abnormal interrupt of the microcontroller by the debugger, and reversely deducing the last statement C.
The microcontroller context data at the time of failure is restored by the debugger manually inputting the PC register, LR register, R12 register, R3 register, R2 register, R1 register, R0 register.
And reversely deducing possible reasons for causing the abnormality of the microcontroller by combining the abnormality number and the data of the fault state register corresponding to the corresponding abnormality.
In the actual fault positioning process, firstly, a last statement before the microcontroller is halted is positioned by collecting a PC register value in data of a stack space before the CPU enters an abnormality, if the last statement corresponds to an abnormality number of 5, the internal bus fault can be obtained, meanwhile, a fault state register of the internal bus fault is 0x04 and is expressed as an 'inaccurate data access violation', and finally, the reason of the microcontroller fault is analyzed to be that a write operation is performed on an unwritable address range.
In this embodiment, when an inaccurate data access conflict occurs, several or more assembly sentences need to be traced forward in combination with the execution flow of the program, so as to analyze the assembly sentences one by one, so as to locate the assembly sentences that are actually in error.
It should be noted that the above scheme is suitable for the problems that the automobile ECU is difficult to find and difficult to locate under the scene that the microcontroller core faults easily occur in the early development and the sample process and the after-sales probability is low when the microcontroller core faults occur.
The above examples merely represent a few embodiments of the present invention, which are described in more detail and are not to be construed as limiting the scope of the present invention. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the invention, which are all within the scope of the invention.
Claims (3)
1. The fault storage and analysis method of the Cortex-M microcontroller is characterized by comprising the following steps of:
s1: when the Cortex-M microcontroller generates fault triggering abnormal interrupt, the Cortex-M microcontroller actively calls a preset abnormal processing routine to directionally collect fault data, and the fault data is stored in a non-initialized RAM space in the Cortex-M microcontroller;
the fault data comprises an abnormal number, stack space data before the CPU enters an abnormality and register data in a fault state;
s2: executing system software reset and initialization by the Cortex-M microcontroller, executing information verification on the fault data in the non-initialized RAM space after the initialization is completed, calling a dem_SetEventStatus function in the Dem module by the Cortex-M microcontroller to transfer the fault data which is completed in verification into the RAM space of the Dem module, and calling an NvM_WriteBlock function by the Dem module to store the fault data which is completed in verification into a nonvolatile memory after the non-initialized RAM space is cleared;
s3: loading an elf file in the fault data through a debugger to start a debugging interface, analyzing a PC register value in stack space data before a CPU enters an exception in the debugging interface, positioning an assembly statement of a Cortex-M microcontroller before the CPU enters the exception, reversely deducing a final assembly, manually inputting the values of the PC register, an LR register, an R12 register, an R3 register, an R2 register, an R1 register and an R0 register according to the final assembly to restore context data of the Cortex-M microcontroller in fault, and reversely deducing the fault cause of the Cortex-M microcontroller by combining the exception number and the register data in fault state;
the abnormal interruption in the step S1 comprises the internal bus fault abnormal interruption, the memory management fault abnormal interruption, the usage fault abnormal interruption and the hard fault abnormal interruption of the Cortex-M microcontroller;
in the Cortex-M microcontroller, the anomaly number and the corresponding fault type in the directionally collected fault data comprise:
number 3 corresponds to a hard failure; number 4 corresponds to a memory management failure; number 5 corresponds to an internal bus fault; number 6 corresponds to the application failure;
in the Cortex-M microcontroller, the corresponding relation between the register data and the abnormal number in the fault state in the fault data is as follows:
if the anomaly number is 3, the data of a hard fault state register is required to be extracted, the register address is 0xE000_ED2C, and the effective length is 32 bits;
if the anomaly number is 4, the data of a 'memory management fault state register' needs to be extracted, and the register address is 0xE000_ED28, and the effective length is 8 bits;
if the anomaly number is 5, the data of 'internal bus fault' needs to be extracted, the register address is 0xE000_ED29, and the effective length is 8 bits;
the exception number is 6, the data of 'usage fault' needs to be extracted, the register address is 0xE000_ED2A, and the effective length is 9 bits;
and (2) storing the fault data in the step (S1) into a non-initialized RAM space, and outputting abnormal fault data of the Cortex-M microcontroller to an external platform through a CAN bus CAN_ID by the Cortex-M microcontroller.
2. The fault storage and analysis method of a Cortex-M microcontroller as claimed in claim 1, wherein: the exception handling routine in step S1 includes: and actively collecting the fault data by the Cortex-M microcontroller, juxtaposing a 'microcontroller fault flag bit' in the Cortex-M microcontroller as effective, and storing the fault data into a non-initialized RAM space after CRC32 check information is added in the fault data.
3. The fault storage and analysis method of a Cortex-M microcontroller as claimed in claim 1, wherein: in the step S2, after the initialization of the Cortex-M microcontroller is completed, the information verification process is as follows:
s2.1: performing CRC32 check information check on fault data in the non-initialized RAM space to judge whether the fault data is complete, and executing step S2.2 if the judging result is complete;
s2.2: judging whether a 'microcontroller fault zone bit' in the non-initialized RAM space is effective, and if the judging result is effective, calling a Dem module to transfer fault data.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310695106.7A CN116430835B (en) | 2023-06-13 | 2023-06-13 | Fault storage and analysis method of Cortex-M microcontroller |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310695106.7A CN116430835B (en) | 2023-06-13 | 2023-06-13 | Fault storage and analysis method of Cortex-M microcontroller |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116430835A CN116430835A (en) | 2023-07-14 |
| CN116430835B true CN116430835B (en) | 2023-09-15 |
Family
ID=87083647
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310695106.7A Active CN116430835B (en) | 2023-06-13 | 2023-06-13 | Fault storage and analysis method of Cortex-M microcontroller |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116430835B (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1477505A (en) * | 2002-08-24 | 2004-02-25 | 深圳市中兴通讯股份有限公司 | Abnormal failure location method in embedded operationi system |
| CN107908495A (en) * | 2017-11-15 | 2018-04-13 | 南京南瑞继保电气有限公司 | A kind of embedded system exception record methods of exhibiting |
| CN111781917A (en) * | 2020-07-03 | 2020-10-16 | 华人运通(江苏)技术有限公司 | Fault data processing method, domain controller and automobile |
| CN113157519A (en) * | 2021-03-04 | 2021-07-23 | 中国航空工业集团公司西安航空计算技术研究所 | Embedded computer system fault auxiliary positioning architecture and method |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE10036278A1 (en) * | 2000-07-26 | 2002-02-07 | Bosch Gmbh Robert | Monitoring the routine of an executed program, involves configuring debug logic to run exceptional condition routine if a program sequence is interrupted during the actual program run time |
| US20220214677A1 (en) * | 2021-01-05 | 2022-07-07 | Samsung Electronics Company, Ltd. | Detecting anomalous events using a microcontroller |
-
2023
- 2023-06-13 CN CN202310695106.7A patent/CN116430835B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1477505A (en) * | 2002-08-24 | 2004-02-25 | 深圳市中兴通讯股份有限公司 | Abnormal failure location method in embedded operationi system |
| CN107908495A (en) * | 2017-11-15 | 2018-04-13 | 南京南瑞继保电气有限公司 | A kind of embedded system exception record methods of exhibiting |
| CN111781917A (en) * | 2020-07-03 | 2020-10-16 | 华人运通(江苏)技术有限公司 | Fault data processing method, domain controller and automobile |
| CN113157519A (en) * | 2021-03-04 | 2021-07-23 | 中国航空工业集团公司西安航空计算技术研究所 | Embedded computer system fault auxiliary positioning architecture and method |
Non-Patent Citations (1)
| Title |
|---|
| 基于AUTOSAR标准的UDS诊断通信;马天才，等;《机电一体化》;第26卷(第5期);34-40 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116430835A (en) | 2023-07-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7127642B2 (en) | System and method for self-diagnosing system crashes | |
| US7991961B1 (en) | Low-overhead run-time memory leak detection and recovery | |
| CN103186461B (en) | The store method of a kind of field data and restoration methods and relevant apparatus | |
| US8291379B2 (en) | Runtime analysis of a computer program to identify improper memory accesses that cause further problems | |
| EP0664511A2 (en) | Microprocessor fault log | |
| CN108710551B (en) | SPARC processor-based single event upset fault injection test method and system | |
| US20100185895A1 (en) | Failure-specific data collection and recovery for enterprise storage controllers | |
| TWI544410B (en) | Diagnosing code using single step execution | |
| US20120297370A1 (en) | Stack Analysis for Post Mortem Analysis | |
| KR20140061443A (en) | Memory dump with expanded data and user privacy protection | |
| US8650547B2 (en) | Method for debugging operational software of a system onboard an aircraft and device for implementing the same | |
| US6961874B2 (en) | Software hardening utilizing recoverable, correctable, and unrecoverable fault protocols | |
| US20100088546A1 (en) | Statistical debugging using paths and adaptive profiling | |
| US20080133975A1 (en) | Method for Running a Computer Program on a Computer System | |
| US20070226471A1 (en) | Data processing apparatus | |
| CN116430835B (en) | Fault storage and analysis method of Cortex-M microcontroller | |
| US7904754B2 (en) | Systems and methods for automated determination of out of memory handling | |
| CN111488288A (en) | Method, device, terminal and storage medium for testing BMC ACD stability | |
| US7415560B2 (en) | Method of automatically monitoring computer system debugging routine | |
| CN114706702A (en) | FADEC operating system-based fault rapid positioning method | |
| CN114385418A (en) | Protection method, device, equipment and storage medium for communication equipment | |
| JP2009223714A (en) | Arithmetic circuit and failure analysis method of arithmetic circuit | |
| CN113986622A (en) | SDK abnormity self-checking method, device, medium and computing equipment | |
| CN116610551A (en) | Code coverage rate calculation method, device, equipment and medium | |
| US20070028218A1 (en) | Apparatus, system, and method for a software test coverage analyzer using embedded hardware |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |