A method for detecting abnormal CPU operation states applicable to ARM architecture

Abstract

The application provides a CPU abnormal operation state detection method suitable for ARM architecture, which combines the chip abnormal detection mechanism and the automobile local area network communication, comprehensively monitors and intelligently analyzes the CPU abnormal state, improves the accuracy and efficiency of CPU abnormal reason positioning, enhances the stability and reliability of the system, and is convenient for programmers to quickly locate the reason of chip reset caused by software vulnerability in the software development stage, and to timely find the CPU abnormality of the controller in the mass production operation stage, and to return the controller fault data to the enterprise test system through remote control, to build a fault environment for fault reproduction and solution.

Description

Technical Field

[0001] This invention relates to a method for detecting abnormal operating states of a CPU applicable to ARM architecture, and pertains to the field of automotive electronic control system technology. Background Technology

[0002] In the field of automotive electronic control, automotive electronic control systems can be reset due to software problems and external factors. Software problems include: array access out of bounds, operation on non-writable addresses, division by zero, and watchdog resets caused by logical infinite loops. External factors include: unstable power supply, electrical noise (such as power line noise), electromagnetic interference, electrostatic discharge, extreme operating environments (such as temperature and mechanical vibration), component wear caused by repeated programming or alternating high and low temperatures (such as Flash / EEPROM devices, crystal oscillators, and capacitors), radiation, usage problems, or illegal external inputs. These problems can cause the CPU-run program to fail to execute.

[0003] When software vulnerabilities are discovered that cause CPU resets or crashes, current techniques typically involve connecting a code debugger to the controller's main control chip for debugging. This involves setting breakpoints, reading stack information, and observing variable values ​​to analyze the location of missed breakpoints and the cause of the vulnerability. For code with anomaly detection enabled, the chip's hardware error detection mechanisms can also be used to detect errors such as internal bus errors and memory management errors. However, for controllers running in vehicles, this method requires debugger support. For the low-probability, sporadic CPU resets and crashes that occur in batches of vehicles, it's problematic because a debugger cannot be equipped for every vehicle, and the anomalies occur randomly. Programmers cannot capture CPU execution data in a timely manner when an anomaly occurs, making it impossible to use this method to analyze and resolve software anomalies occurring during actual vehicle operation.

[0004] Existing technologies also use fault diagnosis code to determine faults in sensors, actuators, BusOff, and memory. If a fault is found, a fault code is recorded, and a diagnostic tool is used to read the fault code and returned data from the controller via the UDS communication protocol. A CPU reset mechanism is also used to reset the CPU pointer to start executing code from the boot address when the program or CPU malfunctions. This method requires the program to run normally to detect expected faults. When an abnormal reset occurs, the fault detection program cannot execute normally, and there is usually no application software specifically for CPU anomaly detection. Therefore, it cannot detect sudden CPU resets caused by software problems or external factors, and cannot troubleshoot intermittent CPU reset crashes. Furthermore, although microprocessors provide features such as watchdog timers and Power-Down Detection (BOD), the watchdog can be set to be triggered when the timer is not cleared within a certain period, which can be used to generate a reset or a Non-Maskable Interrupt (NMI). BOD can generate a reset when the supply voltage drops to a certain level. However, when program execution fails and the processor stops responding, the watchdog timer takes some time to activate. For applications with extremely high real-time requirements, such as automotive powertrain and chassis electronic control systems, even an unexpected delay of 1 millisecond can cause the entire control system to malfunction, resulting in unacceptable consequences. Furthermore, mechanisms such as watchdog reset cannot provide debugging information that facilitates troubleshooting during the mass production and operation of vehicles, and are not helpful in locating code bugs. Summary of the Invention

[0005] To address the problems existing in the prior art, this invention provides a method for detecting abnormal CPU operating states applicable to ARM architecture. By combining the chip's abnormal detection mechanism with automotive local area network communication, it enables comprehensive monitoring and intelligent analysis of abnormal CPU states, improving the accuracy and efficiency of CPU abnormality cause location, and enhancing system stability and reliability.

[0006] This invention is achieved using the following technical solution:

[0007] This invention proposes a method for detecting abnormal CPU operation states applicable to ARM architecture, the specific technical solution of which is as follows:

[0008] A method for detecting abnormal CPU operating states applicable to ARM architecture includes the following steps:

[0009] Step 1: Execute the error exception handling code function when a CPU exception is detected;

[0010] Step 2: In this function, check whether the non-volatile memory is working properly; if yes, read and store the data in the stack memory space, the current RTC clock time, the data in the CSA memory space, the data in the CFSR, HFSR, MMFAR, BFAR, and AFSR registers, the number of exceptions, the operating status of the actuator, and the sensor data input values ​​into the Flash; if no, proceed to step 3.

[0011] Step 3: In the error handling code function, determine whether the control system can be shut down smoothly; if yes, notify the vehicle control to enter limp state through the vehicle communication protocol, and execute control commands in the vehicle electronic controller to shut down the control system; if no, proceed to step 4.

[0012] Step 4: Perform a reset and restart. If the entire control system has not stopped smoothly and is still running, and the storage function is normal, read the actuator state stored before the reset and set the actuator to that state.

[0013] Step 5: Check if the CAN / Ethernet communication is normal; if normal, send the data in the stack memory space, the current RTC clock time, the data in the CSA memory space, the data in the CFSR, HFSR, MMFAR, BFAR, and AFSR registers, and the number of exceptions to the cloud server for recording via in-vehicle communication; if abnormal, perform a reset and restart and then check again until normal.

[0014] Step 6: Design the memory data backhaul function of the automotive electronic controller. The code and runtime data stored in memory are backhauled to the enterprise server for storage via a protocol. The code is then flashed to the same automotive electronic controller on the enterprise test platform using a code debugger for local environment reproduction.

[0015] Preferably, in step 1, the execution of the error exception handling code function when a CPU abnormality is detected is based on the hardware error exception mechanism provided by the ARM Cortex-M3 and Cortex-M4 processors; the error exception handling code function is the Error_Hook function; when a CPU abnormality is detected, the chip's HardFault exception is triggered and the Error_Hook function is entered.

[0016] Preferably, in step 5, the detection of whether the CAN / Ethernet communication is normal can be performed after step 1. If normal, the data in the stack memory space, the current RTC clock time, the data in the CSA memory space, the data in the CFSR, HFSR, MMFAR, BFAR, and AFSR registers, and the number of abnormal occurrences are sent to the cloud server for recording via in-vehicle communication. If abnormal, step 4 is executed to reset and restart, and then the detection is performed again.

[0017] Preferably, in step 6, the code in memory and the stored runtime data are sent back to the enterprise server for storage via the J1939 protocol; and the code is flashed to the same automotive electronic controller on the enterprise test platform via the JTAG debugging protocol of the code debugger for local environment reproduction.

[0018] Preferably, in step 6, the data transmission supports the function of resuming interrupted transmission. The automotive electronic controller monitors the communication data flow with the enterprise server in real time, records the memory address of the transmitted data when the communication is interrupted, and uses this address as the starting address of the data transmission to continue the data transmission when the connection is next established.

[0019] Preferably, the error handling code function is designed with a printing function to receive the printing information sent by the CPU through the code debugger and display it in the debugging interface. The content includes data in the stack memory space, the current RTC clock time, data in the CSA memory space, CFSR, HFSR, MMFAR, BFAR, AFSR register data, the number of exceptions, etc., to intuitively prompt the programmer that a program exception has occurred and the address of the exception program.

[0020] Preferably, during the execution of error handling code, the occurrence time of sleep / wake-up events is monitored in real time, and the changes in power supply are also monitored. When it is found that the wake-up source is effective but the power supply voltage drops rapidly, but can still support CPU operation, the rapid power-down event is recorded, and the fault is sent to the instrument via the J1939 protocol DM1 message to prompt the driver to inspect the vehicle.

[0021] Preferably, the monitoring software monitors the execution time of the application software in real time during the software operation to see if there are large changes or timeouts. If so, it records the starting address of the application software with the problem in memory, then triggers the software to enter the error exception handling code function, and prints the execution time exception event and the maximum execution time to the code debugger interface.

[0022] Preferably, the automotive electronic controller has a CPU abnormal state detection and alarm function, which transmits the CPU abnormal information stored in memory to the abnormal register information parsing software running on a PC or enterprise server via CAN / Ethernet.

[0023] Furthermore, the CPU abnormal state detection alarm function is characterized by transmitting the stored CPU abnormal information locally to the laptops of maintenance technicians and software engineers via CAN / Ethernet communication. The laptops are connected to the vehicle's electronic controllers that have experienced abnormal resets via the vehicle's OBD interface. The abnormal register information parsing software running on the laptops can read the abnormal register information stored in the vehicle's electronic controllers for detecting software vulnerabilities.

[0024] The beneficial effects of this invention are:

[0025] This invention enables programmers to quickly locate the cause of chip reset due to software vulnerabilities during the software development phase, as well as to promptly detect CPU anomalies during mass production and operation. It also enables remote transmission of automotive electronic controller fault data back to the enterprise testing system to construct a fault environment for fault reproduction and resolution. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating the CPU anomaly handling process during the mass production and operation phase of a CPU anomaly detection method applicable to ARM architecture, as described in this invention.

[0027] Figure 2 This is a flowchart illustrating the CPU exception handling process during the software development and debugging phase of a CPU exception detection method applicable to ARM architecture. Detailed Implementation

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

[0029] Definitions of abbreviations and key terms:

[0030] 1. CPU: Central Processing Unit.

[0031] 2. ARM: Advanced RISC Machines, referring to a CPU architecture.

[0032] 3. J1939: A vehicle communication protocol based on CAN bus.

[0033] 4. UDS: Unified Diagnostic Service, a communication protocol used for vehicle fault diagnosis.

[0034] 5. CAN: Controller Area Network, a type of communication network within a vehicle.

[0035] 6. Error Hook: A function used to analyze problematic code segments.

[0036] 7.CFSR: A register that can be configured to display error status information.

[0037] 8. HFSR: Hardware error status register.

[0038] 9. MMFAR: A register that stores the address accessed when a memory management error is triggered.

[0039] 10. BFAR: A register that stores the address accessed when a bus error is triggered.

[0040] 11. AFSR: Device-defined error status register.

[0041] 12. CSA: Context Save Area.

[0042] like Figure 1 As shown, during the mass production and operation phase, this invention proposes a method for detecting abnormal CPU operating states applicable to the ARM architecture, comprising the following steps:

[0043] Step 1: Execute the error exception handling code function when a CPU exception is detected; Executing the error exception handling code function when a CPU exception is detected is based on the hardware error exception mechanism provided by the ARM Cortex-M3 and Cortex-M4 processors; The error exception handling code function is the Error_Hook function; By default, when a CPU exception is detected, the chip's HardFault exception will be triggered and the Error_Hook function will be entered;

[0044] Step 2: In this function, check whether the NvM (non-volatile memory) function is working properly; if yes, read and store the data in the stack memory space, the current RTC clock time, the data in the CSA memory space, the CFSR, HFSR, MMFAR, BFAR, and AFSR register data, the number of occurrences of various exceptions, the operating status of safety-related actuators, and the sensor data input values ​​into the Flash memory; if no, proceed to step 3.

[0045] Step 3: In the error handling code function, determine whether the control system can be shut down smoothly based on the current function and operating status of the control system; if yes, notify other controllers in the vehicle to enter limp state through the vehicle communication protocol, and execute control commands in the vehicle electronic controller to shut down the control system; if no, proceed to step 4.

[0046] Step 4: Perform a reset and restart. If the entire control system has not stopped smoothly and is still running, and the storage function is normal, the actuator state stored before the reset is read and the actuator is set to that state to reduce the impact of the abnormal reset process on the automotive electronic control system.

[0047] Step 5: Check if the CAN / Ethernet communication is normal; if normal, send the data in the stack memory space, the current RTC clock time, the data in the CSA memory space, the data in the CFSR, HFSR, MMFAR, BFAR, and AFSR registers, and the number of exceptions to the cloud server for recording via in-vehicle communication; if abnormal, perform a reset and restart and then check again until normal.

[0048] Step 6: Design the automotive electronic controller's memory data backhaul function. Use the J1939 protocol to backhaul the code and stored runtime data from memory to the enterprise server. Then, use the JTAG debugging protocol of a code debugger to flash the data onto the same automotive electronic controller on the enterprise test platform for local environment reproduction. Data transmission supports breakpoint resumption. The automotive electronic controller monitors the communication data stream with the enterprise server in real time, records the memory address of the transmitted data when communication is interrupted, and uses this address as the starting address to resume data transmission upon the next connection.

[0049] In step 5, the CAN / Ethernet communication is checked after step 1. If it is normal, the data in the stack memory space, the current RTC clock time, the data in the CSA memory space, the CFSR, HFSR, MMFAR, BFAR, AFSR register data, and the number of abnormal occurrences are sent to the cloud server for recording via in-vehicle communication. If it is abnormal, step 4 is executed to reset and restart, and then the test is performed again.

[0050] The error handling code function is designed with a printing function. It receives the printing information sent by the CPU through the code debugger and displays it in the debugging interface. The content includes data in the stack memory space, the current RTC clock time, data in the CSA memory space, CFSR, HFSR, MMFAR, BFAR, AFSR register data, the number of exceptions, etc., which are used to intuitively prompt the programmer that a program exception has occurred and the address of the exception program.

[0051] During the execution of error and exception handling code, the occurrence time of sleep and wake-up events is monitored in real time, and the changes in power supply are also monitored. When it is found that the wake-up source is effective but the power supply voltage drops rapidly, but can still support the CPU to run, the rapid power-down event is recorded. At this time, there may be faults such as loose connections in the power supply harness. The fault is sent to the instrument through the J1939 protocol DM1 message to prompt the driver to inspect the vehicle.

[0052] The monitoring software continuously monitors the application's execution time for significant fluctuations and timeouts during software operation. If any issues are found, it records the application's starting address in memory, triggers the software to enter the error handling function, and prints the execution time exception event and maximum execution time to the debugger interface. The monitoring software also has the function of calculating the maximum runtime of each task. It can monitor the task number and maximum runtime of tasks that have timed out. When the monitoring software detects any task timeout, it executes the CPU exception trigger function, causing the CPU to enter the Error_Hook function, which is used to notify the software development team of the task timeout. In multi-tasking systems, conflicting tasks can be terminated and reactivated.

[0053] This invention includes a code debugger host computer and a C / Python parsing script for exception register information based on the code debugger host computer. When the CPU enters an exception state, the script can read the status value of the exception register and display the exception type, the function that caused the exception, the number of lines of code in the function that caused the exception, and the input parameters of the function in text form.

[0054] This invention features an added function of storing exception register information on top of the hardware exception detection mechanism of ARM chips. This allows software engineers to detect the cause of a software reset at any time after a CPU exception occurs, without needing to capture the exact moment of the reset. The exception register information storage function also enables remote notification to the enterprise server of CPU exceptions in the corresponding vehicle and controller. The enterprise server can record the vehicle's frame number, the controller part number where the CPU exception occurred, and the time of the CPU exception.

[0055] This invention relates to an automotive electronic controller with a CPU anomaly detection and alarm function. It transmits CPU anomaly information stored in memory to anomaly register information parsing software running on a PC or enterprise server via CAN / Ethernet. The CPU anomaly detection and alarm function also allows for local transmission of stored CPU anomaly information to the laptops of repair technicians and software engineers via CAN / Ethernet communication. By connecting the laptop to the automotive electronic controller in the vehicle that has experienced an anomaly reset via the vehicle's OBD interface, the anomaly register information parsing software running on the laptop can read the anomaly register information stored in the automotive electronic controller for software vulnerability detection. Furthermore, the CPU anomaly detection and alarm function also features the ability to transmit all locally stored operating data in memory, such as calibration data, remaining mileage, and fault data, locally or remotely to a PC or enterprise server via CAN / Ethernet communication, for reproducing the environmental data of the anomaly on a test bench.

[0056] like Figure 2As shown, during the software development and debugging phase, this invention connects the code debugger on a laptop computer to the main chip of the automotive electronic controller. When a CPU exception occurs, the chip exception detection mechanism is triggered, and the error exception handling code function is entered. This information can be displayed in the debugging interface of the laptop computer, including data in the stack memory space, the current RTC clock time, data in the CSA memory space, CFSR, HFSR, MMFAR, BFAR, AFSR register data, and the number of exceptions, which facilitates intuitive testing by maintenance technicians and software engineers.

[0057] This invention discloses a method for detecting abnormal CPU operating states applicable to ARM architecture. By combining the chip's abnormal detection mechanism with automotive local area network communication, it enables comprehensive monitoring and intelligent analysis of abnormal CPU states, improving the accuracy and efficiency of CPU abnormality cause location and enhancing system stability and reliability.

[0058] Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for detecting abnormal operating states of a CPU suitable for ARM architecture, characterized in that, Includes the following steps: Step 1: Execute the error exception handling code function when a CPU exception is detected; Step 2: In this function, check whether the non-volatile memory is working properly; if yes, read and store the data in the stack memory space, the current RTC clock time, the data in the CSA memory space, the data in the CFSR, HFSR, MMFAR, BFAR, and AFSR registers, the number of exceptions, the operating status of the actuator, and the sensor data input values ​​into the Flash; if no, proceed to step 3. Step 3: In the error handling code function, determine whether the control system can be shut down smoothly; if yes, notify the vehicle control to enter limp state through the vehicle communication protocol, and execute control commands in the vehicle electronic controller to shut down the control system; if no, proceed to step 4. Step 4: Perform a reset and restart. If the entire control system has not stopped smoothly and is still running, and the storage function is normal, read the actuator state stored before the reset and set the actuator to that state. Step 5: Check if the CAN / Ethernet communication is normal; if normal, send the data in the stack memory space, the current RTC clock time, the data in the CSA memory space, the data in the CFSR, HFSR, MMFAR, BFAR, and AFSR registers, and the number of exceptions to the cloud server for recording via in-vehicle communication; if abnormal, perform a reset and restart and then check again until normal. Step 6: Design the memory data backhaul function of the automotive electronic controller. The code and runtime data stored in memory are backhauled to the enterprise server for storage via a protocol. The code is then flashed to the same automotive electronic controller on the enterprise test platform using a code debugger for local environment reproduction.

2. The method for detecting abnormal CPU operation status applicable to ARM architecture according to claim 1, characterized in that, In step 1, the execution of the error exception handling code function when a CPU abnormality is detected is based on the hardware error exception mechanism provided by the ARM Cortex-M3 and Cortex-M4 processors; the error exception handling code function is the Error_Hook function; when a CPU abnormality is detected, the chip's HardFault exception is triggered and the Error_Hook function is entered.

3. The method for detecting abnormal CPU operation status applicable to ARM architecture according to claim 1, characterized in that, In step 5, the CAN / Ethernet communication is checked after step 1. If it is normal, the data in the stack memory space, the current RTC clock time, the data in the CSA memory space, the CFSR, HFSR, MMFAR, BFAR, AFSR register data, and the number of abnormal occurrences are sent to the cloud server for recording via in-vehicle communication. If it is abnormal, step 4 is executed to reset and restart, and then the test is performed again.

4. The method for detecting abnormal CPU operation status applicable to ARM architecture according to claim 1, characterized in that, In step 6, the code in memory and the stored runtime data are sent back to the enterprise server for storage via the J1939 protocol; the code is then flashed to the same automotive electronic controller on the enterprise test platform via the JTAG debugging protocol of the code debugger for local environment reproduction.

5. The method for detecting abnormal CPU operation status applicable to ARM architecture according to claim 1, characterized in that, In step 6, data transmission supports breakpoint resume function. The automotive electronic controller monitors the communication data flow with the enterprise server in real time, records the memory address of the transmitted data when communication is interrupted, and uses this address as the starting address for data transmission to continue when the connection is next established.

6. The method for detecting abnormal CPU operation status applicable to ARM architecture according to claim 1, characterized in that, The error handling code function is designed with a printing function. It receives the printing information sent by the automotive electronic controller through the code debugger and displays it in the debugging interface. The content includes data in the stack memory space, the current RTC clock time, data in the CSA memory space, CFSR, HFSR, MMFAR, BFAR, AFSR register data, and information on the number of exceptions. This is used to intuitively prompt the programmer that a program exception has occurred and the address of the exception program.

7. The method for detecting abnormal CPU operation status applicable to ARM architecture according to claim 1, characterized in that, During the execution of error and exception handling code, the occurrence time of sleep and wake-up events is monitored in real time, and the changes in power supply are also monitored. When it is found that the wake-up source is effective but the power supply voltage drops rapidly, but can still support the CPU to run, the rapid power-down event is recorded, and the fault is sent to the instrument through the J1939 protocol DM1 message to prompt the driver to have the vehicle inspected.

8. The method for detecting abnormal CPU operation status applicable to ARM architecture according to claim 1, characterized in that, The monitoring software monitors the execution time of the application software in real time during the software's operation to see if there are large changes or timeouts. If so, it records the starting address of the application software with the problem in memory, then triggers the software to enter the error exception handling code function, and prints the execution time exception event and the maximum execution time to the code debugger interface.

9. The method for detecting abnormal CPU operation status applicable to ARM architecture according to claim 1, characterized in that, The automotive electronic controller has a CPU abnormal state detection and alarm function, which transmits the CPU abnormal information stored in memory to the abnormal register information parsing software running on a PC or enterprise server via CAN / Ethernet.

10. A method for detecting abnormal CPU operating states applicable to ARM architecture according to claim 9, characterized in that, The CPU abnormal state detection and alarm function also has the ability to locally transmit the stored CPU abnormal information to the laptops of maintenance technicians and software engineers via CAN / Ethernet communication. The laptop is connected to the vehicle's electronic controller that has experienced an abnormal reset through the vehicle's OBD interface. The abnormal register information parsing software running on the laptop can read the abnormal register information stored in the vehicle's electronic controller for the purpose of detecting software vulnerabilities.

Images