Software fault diagnosis method for electronic control unit

Abstract

The application relates to a software fault diagnosis method for an electronic control unit, which comprises the following steps: monitoring the running state of software in the electronic control unit based on a watchdog timer; when the software fails to reset the watchdog timer within a preset timeout period, generating a timeout event and triggering a non-maskable interrupt associated with the timeout event, executing a corresponding interrupt service program to capture software context information at a fault moment; storing the software context information into a predetermined memory area whose content is maintained after the electronic control unit is reset; and reading the software context information stored in the predetermined memory area through a communication interface after the electronic control unit is reset. The application has the effect that high-value underlying software context information at a fault occurrence moment can be automatically and reliably captured without the need of physically connecting a debugger and without the need of reproducing the fault.

Description

Technical Field

[0001] This application relates to the field of automotive control, and in particular to a method for diagnosing software faults in electronic control units. Background Technology

[0002] In the modern automotive industry, the electronic control unit (ECU) is a core component of the vehicle system, and the reliability, stability, and security of its software have become the cornerstone of the overall vehicle safety system. To ensure that the ECU can recover normally when encountering unexpected software anomalies, such as getting stuck in an infinite loop, logical errors, or memory access conflicts that cause the program execution flow to stall, the industry commonly uses a watchdog timer as a standard system safety mechanism. The watchdog is a hardware timer module. During normal operation, the software in the ECU periodically resets it to indicate that it is functioning correctly. Once the software becomes unresponsive and fails to reset the timer on time, the watchdog times out and forcibly triggers a system hardware reset. This mechanism effectively allows the ECU to recover from a paralyzed state, ensuring the basic functional safety of the vehicle.

[0003] However, while watchdog resets mitigate the risk of persistent software freezes, the forced restart process itself can significantly negatively impact the user experience. For example, while driving, the dashboard might suddenly flash, certain warning lights might be briefly triggered, or the infotainment system might experience a momentary freeze or blackout. These brief occurrences are enough to cause driver confusion and anxiety, reducing perceived product quality and brand trust. Therefore, automakers typically require suppliers to identify and eliminate the root cause of software freezes, rather than relying solely on watchdog timers for passive recovery.

[0004] The root cause of these types of software failures that trigger the watchdog timer is extremely difficult to pinpoint. In real-world road environments, these software failures often exhibit strong intermittentness, occurring only once every two weeks or even longer, with no discernible triggering pattern. This low-frequency and random characteristic renders traditional laboratory debugging methods almost completely ineffective. Development engineers cannot reliably reproduce the problem on a test bench by connecting a hardware debugger, and therefore cannot interrupt program execution when a failure occurs to examine the register state and function call stack at that moment.

[0005] Another auxiliary method is to pre-install points in the software to output a large amount of runtime logs or tracing information via the communication bus. By analyzing the last log printed before the failure occurred, the approximate execution path of the program can be inferred. However, this method itself will affect the runtime sequence of the software, which may cause the original intermittent problems to disappear or shift. Furthermore, at the moment when the system is about to crash, the log output function itself may be abnormal, resulting in incomplete or inaccurate information. In addition, modern vehicles generally support remote diagnostics based on protocols such as unified diagnostic services. However, these diagnostic protocols are mainly used to diagnose known, preset fault scenarios, not designed for debugging unknown, catastrophic software program crashes.

[0006] In summary, current technologies lack a mechanism to automatically and reliably capture high-value low-level software context information at the moment a fault occurs, without requiring a physical connection to a debugger or the reproduction of the fault, in addressing the problem of intermittent software freezing in electronic control units. Summary of the Invention

[0007] In order to automatically and reliably capture high-value low-level software context information at the moment of a fault occurrence without the need for a physical connection to a debugger or the need to reproduce the fault, this application provides a software fault diagnosis method for electronic control units.

[0008] This application provides a software fault diagnosis method for electronic control units, which adopts the following technical solution:

[0009] A software fault diagnosis method for an electronic control unit includes the following steps:

[0010] S1. The operating status of the software in the electronic control unit is monitored based on the watchdog timer. When the software fails to reset the watchdog timer within the preset timeout period, a timeout event is generated by the watchdog timer.

[0011] S2. Trigger a non-maskable interrupt associated with the timeout event based on the timeout event;

[0012] S3. In response to the non-maskable interrupt, execute the corresponding interrupt service routine to capture the software context information at the time of the fault;

[0013] S4. Store the software context information in a predetermined memory area whose contents are retained after the electronic control unit is reset;

[0014] S5. After the electronic control unit is reset, the software context information stored in the predetermined memory area is read through the communication interface for use in diagnosing and analyzing software faults.

[0015] By adopting the above technical solution, the watchdog timer timeout event is associated with a non-maskable interrupt, establishing a fault information capture path that is guaranteed to execute before the system hardware reset. This mechanism leverages the hardware characteristic that non-maskable interrupts cannot be masked by software, ensuring that the capture action can be reliably triggered during software anomalies, thus solving the technical problem of traditional watchdog resets directly causing the loss of contextual information. The service routine executed in response to this interrupt captures the software context information at the time of the fault and stores it in a predetermined memory area whose contents are preserved after a reset, allowing critical diagnostic information to be retained across hardware reset cycles. After the system restarts, the software context information stored in this area is read through the communication interface, providing a data source for remote diagnostics and offline analysis, avoiding the need to reproduce intermittent faults in a laboratory environment.

[0016] Optionally, the software context information includes function call history and process stack memory, wherein the function call history is used to record the software execution path before the failure occurred, and the process stack memory is used to store the local variables, parameters and return addresses of the function calls when the failure occurred.

[0017] By adopting the above technical solution, the software context information is specifically defined as including function call history and process stack memory. The function call history is used to reconstruct the software execution path before the failure occurred, while the process stack memory is used to store local variables, parameters, and return addresses at the time of the failure. The combination of these two parts of information provides the necessary basis for analyzing complex logical errors or data-dependent failures, thereby elevating diagnostic capabilities from simple fault state recording to the level of root cause analysis.

[0018] Optionally, step S3 includes the following sub-steps:

[0019] S31. Traverse the CSA linked list automatically generated by the processor hardware to capture the function call history; wherein, CSA is the context storage area, and PCXI is the previous context information; the linked list consists of multiple CSA nodes, each CSA node is linked to the previous CSA node through a PCXI pointer, the traversal starts from the current context information pointer and backtracks according to the PCXI pointer stored in each CSA node until the end of the linked list;

[0020] S32. Based on the stack pointer register value at the time of the fault and the predefined stack boundary information, copy the contents of the corresponding stack memory region to capture the process stack memory.

[0021] By employing the above technical solution, the function call history is obtained by traversing the Context Saver (CSA) linked list automatically generated by the processor hardware. Utilizing the PCXI pointer, the previous context information contained in each CSA node, the interrupt service routine can perform a chain-like backtracking from the latest CSA node until the entire call chain is traversed. Simultaneously, by reading the stack pointer register value at the time of the fault and combining it with predefined stack boundary information, the contents of the stack memory region directly related to the fault are accurately copied. These two sub-steps decompose the abstract capture action into executable operations based on specific hardware data structures and register states, ensuring the accuracy and completeness of information capture.

[0022] Optionally, each CSA node is a data structure defined by the processor hardware, which includes at least:

[0023] A PCXI pointer used to link to the previous CSA node;

[0024] A register field used to store the function's return address, to determine the location in the code where the current function should return after execution;

[0025] A stack pointer register field is used to store the top of the current stack frame to locate the memory region where local variables and parameters associated with this function call are located;

[0026] Multiple general-purpose register fields are used to store the processor core's operating state, saving intermediate values ​​for data calculation and processing in the event of a failure.

[0027] By adopting the above technical solution, the internal data structure of the CSA node in the context storage area is limited. By specifying that this data structure must include a PCXI pointer, a return address register field, a stack pointer register field, and a general-purpose register field, it is ensured from the data source level that all basic information units required to reconstruct the fault scene are automatically captured by the hardware.

[0028] Optionally, step S31 includes the following sub-steps:

[0029] S311. Obtain the entry pointer of the current context automatically saved by the processor hardware when the non-maskable interrupt is triggered, and the entry pointer points to the latest CSA node;

[0030] S312. Based on the entry pointer, read and record the software context contained in the latest CSA node as the first recording point of the function call history;

[0031] S313. Extract the stored PCXI pointer from the currently read CSA node;

[0032] S314. Determine whether the PCXI pointer points to a valid, preceding CSA node address: if yes, jump to the preceding CSA node pointed to by the PCXI pointer and repeat steps S312 and S313; if no, end the traversal.

[0033] S315. Combine all recorded software contexts in reverse order of traversal backtracking to reconstruct the complete function call history from the initial function call to the point of failure.

[0034] By employing the above technical solution, starting with obtaining the latest CSA node entry pointer, the system iteratively reads the current node information and extracts the PCXI pointer to locate the next node, ultimately completing the backtracking of the entire call chain. After the traversal is complete, the recorded context information is reverse-sorted and combined to reconstruct the function call history that matches the actual execution order.

[0035] Optionally, step S2 includes the following sub-steps:

[0036] S21. During the initialization phase of the electronic control unit, an interrupt system is configured to set the timeout event of the watchdog timer as a trap request source;

[0037] S22. The service request from the trap request source is routed to the non-maskable interrupt vector of the electronic control unit;

[0038] S23. Enable the trap corresponding to the non-maskable interrupt to ensure that when the timeout event occurs, any currently executing task can be forcibly interrupted and the process can jump to the preset non-maskable interrupt service routine entry address.

[0039] By adopting the above technical solution, by setting the watchdog timeout event as the trap request source and routing its service request to the non-maskable interrupt vector, the trap is finally enabled, thus establishing a hardware-guaranteed logical path between the timeout event and the non-maskable interrupt.

[0040] Optionally, step S4 includes the following sub-steps:

[0041] S41. Construct a data structure containing a predefined data header, wherein the data header is used to encapsulate the software context information, and the data header includes at least a status flag bit for indicating data validity and a checksum for verifying data integrity;

[0042] S42. Fill the captured software context information into the designated area of ​​the data structure, calculate the checksum of the entire data structure content, and update the checksum field of the data header;

[0043] S43. Write the entire contents of the data structure into the predetermined memory area at once;

[0044] S44. After the data writing is completed, set the status flag bit of the data header to valid to mark that the fault information was successfully stored.

[0045] By employing the above technical solution, and encapsulating context information through a data header containing status flags and a checksum, data verifiability is ensured. During the write operation, the context information is filled in first, and the checksum is calculated. Only after all content has been written is the status flag set to valid as the final step. This write sequence design ensures that external diagnostic devices will not read incomplete or corrupted data caused by interruptions during the write process.

[0046] Optionally, S5 includes:

[0047] In response to an external diagnostic device, a specific data read request is sent via a diagnostic communication protocol, and the software context information stored in the predetermined memory area is returned as response data.

[0048] Optionally, the predetermined memory region is configured as a non-initialized RAM region that skips initialization operations during system startup.

[0049] By adopting the above technical solution and configuring it as a non-initialized RAM area that skips initialization operations during system startup, it is ensured from the bottom layer that the bootloader or startup code will not accidentally erase the captured fault data when the system restarts.

[0050] Optionally, the non-maskable interrupt has the characteristic that it can still be triggered when the global interrupt is disabled or during the execution of other interrupt service routines, so as to ensure the execution of S3.

[0051] By adopting the above technical solution and leveraging its hardware characteristic of being able to be triggered even when global interrupts are disabled or during the execution of other interrupt service routines, the highest level of reliability guarantee is provided for the execution of S3. This characteristic ensures that the fault scene capture action can be forcibly executed regardless of the abnormal state in which the software fails.

[0052] Optionally, an offline analysis step may also be included, which includes:

[0053] On an external computer, by combining the read software context information with the symbol information file of the corresponding software version, the original memory addresses and data in the software context information are parsed into function names, source code line numbers, and variable values ​​that can be analyzed.

[0054] By adopting the above technical solution, the raw memory addresses and data read are combined with the symbol information file of the software version and parsed into function names, source code line numbers and variable values ​​that developers can understand, which helps to improve the efficiency and accuracy of fault diagnosis. Attached Figure Description

[0055] Figure 1 A flowchart illustrating a software fault diagnosis method for an electronic control unit according to an embodiment of the present invention is shown.

[0056] Figure 2 A flowchart illustrating the S1 sub-step in one embodiment of the present invention is shown.

[0057] Figure 3 A flowchart illustrating the S2 sub-step in one embodiment of the present invention is shown.

[0058] Figure 4 A schematic diagram of the context storage area (CSA) in one embodiment of the present invention is shown.

[0059] Figure 5 A flowchart illustrating sub-step S41 in one embodiment of the present invention is shown.

[0060] Figure 6 A flowchart illustrating sub-step S4 in one embodiment of the present invention is shown. Detailed Implementation

[0061] The present application will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of the application and are not intended to limit the scope of the application.

[0062] In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding of the inventive concept. As part of this specification, some of the accompanying drawings of this disclosure are block diagrams illustrating structures and devices to avoid complicating the disclosed principles. For clarity, not all features of the actual embodiment need to be described. Furthermore, the language used in this disclosure has been primarily chosen for readability and instructional purposes and may not have been chosen to define or limit the subject matter of the invention, thus requiring the necessary claims to determine such inventive subject matter. References to “an embodiment” or “an embodiment” in this disclosure mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment, and multiple references to “an embodiment” or “an embodiment” should not be construed as necessarily referring to the same embodiment.

[0063] Unless explicitly defined, the terms “a,” “an,” and “the” are not intended to refer to a singular entity, but rather to include a general category whose specific examples can be used for illustration. Therefore, the use of the terms “a” or “an” can mean any number of at least one, including “a,” “one or more,” “at least one,” and “one or more.” The term “or” means any of the options and any combination of the options, including all options unless explicitly indicated that the options are mutually exclusive. The phrase “at least one of” when combined with a list of items refers to a single item in the list or any combination of items in the list. The phrase does not require all items listed unless explicitly defined as such.

[0064] The Electronic Control Unit (ECU) of an automotive vehicle is an embedded system responsible for specific functions in a modern vehicle. Its core is a microcontroller (MCU). The ECU's software runs on the MCU, reading sensor inputs and performing a series of complex logic and algorithm calculations to control actuators, thereby achieving functions such as engine management, automatic transmission, and vehicle stability control. To ensure driving safety, the ECU integrates a hardware safety module called a watchdog timer. During normal software operation, this timer needs to be reset periodically; this is commonly known as "feeding the dog." If the software stops responding due to an infinite loop or other fatal error, it will be unable to reset the watchdog timer on time. Upon timeout, a forced system hardware reset will be triggered, restoring the ECU from a paralyzed state and preventing risks caused by continuous software failure.

[0065] However, while the watchdog reset mechanism can restore ECU functionality, its forced restart process itself can trigger a series of transient anomalies, such as dashboard flickering or infotainment system lag, negatively impacting the user experience. Therefore, locating and eliminating the root cause of the software freeze is crucial. The reset operation itself destroys all software context information at the moment the fault occurred, including CPU register states, function call stacks, and variable values ​​in memory, making post-incident analysis impossible.

[0066] Because these types of software failures are often highly intermittent, occurring only once every few weeks and without a clear pattern of recurrence, traditional laboratory debugging methods—such as using hardware debuggers to reproduce and capture the failure scenario—become impractical. To address this issue, related technologies have attempted to pre-embed tracking points in the software, outputting large amounts of runtime logs or tracing information via a communication bus. By analyzing the last log printed before the failure occurred, the approximate execution path of the program can be inferred. However, this method itself affects the software's runtime sequence, potentially causing the original intermittent problem to disappear or shift.

[0067] Therefore, this application discloses a software fault diagnosis method for electronic control units, referring to... Figure 1 This includes the following steps S1-S5.

[0068] S1. The operating status of the software in the electronic control unit is monitored based on the watchdog timer. When the software fails to reset the watchdog timer within the preset timeout period, a timeout event is generated by the watchdog timer.

[0069] The watchdog timer monitors the software's operational status through an internal, continuously incrementing hardware counter. The ECU's software is designed to periodically write a specific key value to the watchdog module during its main loop or critical task execution path. This operation resets the watchdog timer, clearing the hardware counter to zero. As long as the software execution flow is as expected and the code to reset the timer is regularly accessible, the hardware counter will not accumulate to a preset timeout threshold. Conversely, when the software malfunctions, such as entering an infinite loop without a timer reset operation or entering an unexpected execution branch due to data errors, the program flow will no longer be able to reach the timer reset code. In this case, the hardware counter will continue to accumulate until it exceeds the preset timeout period. This state is achieved when the watchdog timer generates a timeout event. This timeout event is manifested at the hardware level as a level-to-level signal or the setting of a specific status register bit. It should be noted that, compared to related technologies, the role of the watchdog in this solution has undergone a fundamental change. It is no longer merely the final executor that triggers system reset, but has been transformed into a high-priority event source for capturing abnormal software states.

[0070] S2. Trigger a non-maskable interrupt associated with the timeout event based on the timeout event.

[0071] In existing technologies, the watchdog timer's timeout event is typically directly connected to the MCU's reset controller, its sole purpose being to trigger an unconditional hardware reset. In this solution, however, the timeout event is used as the source to trigger a non-maskable interrupt (NMI). A NMI is a special type of interrupt in a microcontroller interrupt system, possessing the highest response priority, and its most critical characteristic is that it cannot be masked or disabled by software instructions.

[0072] Non-maskable interrupts have the characteristic of being able to be triggered even when global interrupts are disabled or during the execution of other interrupt service routines. When software executes critical code segments with extremely strict timing requirements or that require atomic operations, it typically temporarily disables global interrupts via instructions to prevent its execution from being interrupted by other ordinary interrupts; such code segments are called critical sections. If the software happens to freeze within such a critical section, all ordinary interrupt requests will be ignored by the hardware. If ordinary interrupts are used to capture the fault context, these interrupt requests will also be masked, leading to capture failure and ultimately resulting in a direct reset and loss of context information. By using non-maskable interrupts, regardless of where the software fault occurs, even within a critical section where global interrupts are disabled, the fault context capture mechanism of this solution can still be forcibly executed.

[0073] To ensure that captured information is retained during subsequent system resets, this solution requires storing the information in a special memory region. Specifically, this predetermined memory region is configured as a non-initialized RAM region that skips initialization operations during system startup. In the ECU's memory space, most RAM regions are initialized by the bootloader or startup code after system power-on or reset, typically by clearing them entirely to ensure the software starts running from a clean, deterministic state. However, the predetermined memory region used in this solution is excluded from this initialization process through a special declaration in the compiler's linker script. This allows the data stored in this region to remain unchanged during the hardware reset ultimately triggered by the watchdog timer. Although skipping initialization operations means that the memory region may contain uncertain random values ​​upon first power-on, this can be compensated for by adding validity flags or checksums to the stored data structures, enabling the diagnostic program to distinguish between valid fault capture data and invalid initial values.

[0074] Specifically, in one embodiment, reference is made to... Figure 2 S2 includes the following sub-steps S21-S23.

[0075] S21. During the initialization phase of the electronic control unit, an interrupt system is configured to set the timeout event of the watchdog timer as a trap request source.

[0076] To achieve the associated triggering described in S2, during the ECU's software initialization phase, the interrupt system within the MCU is configured in hardware. The interrupt system is the core logic unit within the MCU responsible for managing and distributing all interrupt requests. First, the watchdog timer's timeout event is set as a trap request source. A trap is a service request directly generated by a hardware module; it is similar to a normal interrupt request but is typically used to handle lower-level system events. This step logically identifies the watchdog timeout signal as an allocable service request source by writing a predefined value to a specific configuration register of the interrupt system.

[0077] S22. The service request from the trap request source is routed to the non-maskable interrupt vector of the electronic control unit.

[0078] Routing here refers to establishing a logical path from the request source to a specific processing unit within the interrupt system. MCU interrupt systems typically include a programmable routing mechanism, allowing developers to direct different interrupt or trap sources to different processing cores or interrupt vectors. A non-maskable interrupt vector is a predefined address in memory that stores the entry address of the non-maskable interrupt service routine. This step, by configuring the relevant routing registers, logically connects the trap request source set in S21 to the non-maskable interrupt vector.

[0079] S23. Enable the trap corresponding to the non-maskable interrupt to ensure that when the timeout event occurs, any currently executing task can be forcibly interrupted and the process can jump to the preset non-maskable interrupt service routine entry address.

[0080] Enabling refers to activating the configured interrupt path and putting it into a standby state. This step is accomplished by setting a specific control bit in the CPU or interrupt controller. Once enabled, the interrupt system begins listening for the trap request. When the watchdog timer subsequently generates a timeout event, the event will be captured by the interrupt system along the path established in S21 and S22 and confirmed as a valid non-maskable interrupt request. This forces the CPU to interrupt any currently executing task and, based on the address in the non-maskable interrupt vector, unconditionally jumps to the entry address of the preset non-maskable interrupt service routine to begin execution.

[0081] Taking the Infineon AURIX series microcontroller as an example, the specific implementation of S21 may correspond to configuring the relevant registers in the system control unit, mapping the watchdog timer timeout request to a service request node. S22 then configures the interrupt router module to direct the output of the service request node to the non-maskable trap of the target CPU. Finally, S23 enables the non-maskable trap by setting the CPU trap control register, thereby completing the entire configuration process.

[0082] S3. In response to the non-maskable interrupt, execute the corresponding interrupt service routine to capture the software context information at the time of the fault. The software context information includes function call history and process stack memory, wherein the function call history is used to record the software execution path before the fault occurred, and the process stack memory is used to store the local variables, parameters, and return addresses of the function calls at the time of the fault.

[0083] The core task of an interrupt service routine is to take a snapshot of the fault situation. Function call history and process stack memory are two key dimensions that constitute this snapshot. Function call history provides macroscopic path information of program execution. For example, a software fault might occur in a scenario where the main function `main()` calls the module initialization function `Module_A_Init()`, which then calls the underlying driver function `Driver_B_Write()`, ultimately entering an infinite loop inside `Driver_B_Write()` due to an invalid pointer access. In this case, the function call history would be represented as a call chain like `main()->Module_A_Init()->Driver_B_Write()`. Process stack memory, on the other hand, provides microscopic data information about the fault point. In the example above, the process stack memory would contain the local variables of the `Driver_B_Write()` function itself, the parameter values ​​passed to it by `Module_A_Init()`, and the code address that `Driver_B_Write()` should return to in `Module_A_Init()` after execution.

[0084] Specifically, in one embodiment, reference is made to... Figure 3 S3 includes the following sub-steps S31-S32.

[0085] S31. Traverse the CSA linked list automatically generated by the processor hardware to capture the function call history; wherein, CSA is the context storage area, and PCXI is the previous context information; the linked list consists of multiple CSA nodes, each CSA node is linked to the previous CSA node through a PCXI pointer, the traversal starts from the current context information pointer and backtracks according to the PCXI pointer stored in each CSA node until the end of the linked list.

[0086] S32. Based on the stack pointer register value at the time of the fault and the predefined stack boundary information, copy the contents of the corresponding stack memory region to capture the process stack memory.

[0087] The Context Saver (CSA) is a dedicated area in memory automatically created by the processor hardware in some microcontroller architectures when a function call or interrupt occurs. It stores critical register information of the current execution environment. The Previous Context Information (PCXI) is a special pointer stored in each newly created CSA, pointing to the address of the previous CSA, thus linking multiple CSAs into a linked list reflecting the call order. The stack pointer register is a dedicated register in the CPU, containing the address of the top of the stack memory region used by the current process. Stack boundary information refers to the start and end addresses of the stack space pre-allocated for each task or process during the software design phase. The stack memory region contains all data stored within this boundary range. The process stack memory is a complete representation of the contents of this region.

[0088] Function call history and process stack memory are both indispensable for fault diagnosis. With only function call history, analysts can only know which function the program executed, but cannot determine what abnormal data or parameters caused the fault. Conversely, with only process stack memory, analysts can see the instantaneous data at the fault point, but due to the lack of call path information, they cannot trace how this abnormal data was generated, nor can they understand why the program reached its current state. Therefore, both must be combined to fully reconstruct the fault scene and conduct effective root cause analysis.

[0089] Specifically, refer to Figure 4 Each CSA node is a data structure defined by the processor hardware, which includes at least:

[0090] A PCXI pointer used to link to the previous CSA node;

[0091] A register field used to store the function's return address, to determine the location in the code where the current function should return after execution;

[0092] A stack pointer register field is used to store the top of the current stack frame to locate the memory region where local variables and parameters associated with this function call are located;

[0093] Multiple general-purpose register fields are used to store the processor core's operating state, saving intermediate values ​​for data calculation and processing in the event of a failure.

[0094] This data structure provides a comprehensive snapshot of the software state at the moment of failure. The PCXI pointer, which links to the previous CSA node, is fundamental for constructing and traversing the call chain, acting like a chain that connects discrete context snapshots. The register field storing the function return address typically holds the contents of the program counter or return address register, clearly defining the hierarchical relationship of function calls and the return path.

[0095] Continuing with the previous example, when a fault occurs within the Driver_B_Write() function, the hardware automatically generates a corresponding CSA node. Within this CSA node, its PCXI pointer field stores the memory address of the CSA node corresponding to the Module_A_Init() function. Its return address register field stores the address of the instruction in the Module_A_Init() function that the Driver_B_Write() function should return to after execution. Its stack pointer register field stores the top address of the current stack frame, which can be used to index the local variables of the Driver_B_Write() function itself and the parameters passed to it by Module_A_Init(). Furthermore, multiple general-purpose register fields used to store the processor core's operating state completely store the instantaneous values ​​of all data and address registers within the CPU at the time of the fault. For example, the address of the invalid pointer that caused the infinite loop, or the value of a critical variable that led to the calculation error, will all be stored in these fields.

[0096] Figure 4 This diagram illustrates how processor hardware automatically packages and stores the internal state (i.e., register contents) of a CPU core register in memory as a linked list when a function call or interrupt occurs. The Context Save Area (CSA) shown in the diagram is a structured block in memory used to store a snapshot of the CPU core registers at a given moment. Depending on the type of context switch, the hardware automatically saves different sets of registers; for example, it saves the preceding set of registers during a function call and the following set during an interrupt or trap. At the end of each CSA memory block is a crucial PCXI field. This field does not store ordinary data but rather a pointer to the memory address of the previous CSA block. It is this PCXI pointer that links the individual CSA blocks in memory, forming a singly linked list that is automatically maintained by the hardware and reflects the call sequence.

[0097] Taking the program execution flow of the previous example as an example, when the main() function calls Function_A, the hardware creates the first CSA block in memory to save the context of main(), and the PCXI pointer of this CSA block is null. Next, when Function_A calls Function_B, the hardware creates another new CSA block to save the context of Function_A, and the PCXI pointer in this new CSA block will point to the address of the first CSA block saved for the main() function. If a software freeze occurs inside Function_B at this time, causing the watchdog timeout to trigger NMI, the hardware will create a third CSA block to save the context at the moment Function_B freezes, and the PCXI pointer in this latest CSA block will point to the address of the CSA block of Function_A. This forms a complete call chain that can be traced back for analysis.

[0098] Specifically, in one embodiment, reference is made to... Figure 5 S31 includes the following sub-steps S311-S315.

[0099] S311. Obtain the entry pointer of the current context automatically saved by the processor hardware when triggered by the non-maskable interrupt, which points to the latest CSA node.

[0100] To capture function call history, the NMI interrupt service routine executes a specific backtracking algorithm. In S311, when the interrupt service routine begins execution, it first retrieves the entry pointer of the current context from a specific system register of the CPU. This pointer is automatically filled in by the processor hardware when responding to NMI, and its value is the memory address of the most recently created CSA node used to store the context at the moment of the fault.

[0101] S312. Based on the entry pointer, read and record the software context contained in the latest CSA node as the first record point of the function call history.

[0102] S313. Extract the stored PCXI pointer from the currently read CSA node.

[0103] S314. Determine whether the PCXI pointer points to a valid, preceding CSA node address: if yes, jump to the preceding CSA node pointed to by the PCXI pointer and repeat steps S312 and S313; if no, end the traversal.

[0104] In S314, the program checks the extracted PCXI pointer. If the pointer is a non-null valid address, it proves that there is a previous caller in the call chain. The program uses this PCXI pointer as the new target address, jumps to the previous CSA node pointed to by that address, and repeats the read record operation in S312 and the extract PCXI pointer operation in S313. This process will continue to loop until the PCXI pointer extracted from a certain CSA node is null or points to a predefined linked list end marker. At this point, the program determines that it has reached the initial node of the call chain, and the traversal process ends.

[0105] S315. Combine all recorded software contexts in reverse order of traversal backtracking to reconstruct the complete function call history from the initial function call to the point of failure.

[0106] Continuing with the aforementioned program execution flow as an example, S311 obtains the entry pointer, which points to the CSA node generated when Function_B gets stuck. S312 records the context of Function_B. S313 extracts the PCXI pointer pointing to the CSA node corresponding to Function_A. S314 checks if this pointer is valid, then jumps and repeats the operation, records the context of Function_A, and extracts the PCXI pointer pointing to the CSA node corresponding to the main() function. S314 checks if this pointer is valid again, then jumps and repeats the operation again, records the context of main(), and extracts its PCXI pointer. At this point, the pointer is null, and the traversal ends.

[0107] Finally, in S315, the program reverses the order of the context information recorded in S312 to S314—namely, the context of Function_B, the context of Function_A, and the context of main(). Through this step, a complete function call history, from the initial function call to the point of failure, is reconstructed, perfectly matching the actual execution flow: main()->Function_A()->Function_B().

[0108] S4. Store the software context information in a predetermined memory area whose contents are retained after the electronic control unit is reset.

[0109] Specifically, in one embodiment, reference is made to... Figure 6 S4 includes the following sub-steps S41-S44.

[0110] S41. Construct a data structure containing a predefined data header, wherein the data header is used to encapsulate the software context information, and the data header includes at least a status flag bit for indicating data validity and a checksum for verifying data integrity.

[0111] First, a predefined data structure is constructed in the uninitialized RAM area. The front of this data structure is a header, which serves as metadata describing the software context information that follows. The header contains at least two key fields: a status flag, a memory unit with a specific value indicating whether the currently stored data is complete and valid; and a checksum, such as a Cyclic Redundancy Check (CRC), a value calculated from the actual bit values ​​of the data content using a specific algorithm, used to verify whether the data has been corrupted during storage when read.

[0112] S42. Fill the captured software context information into the designated area of ​​the data structure, calculate the checksum of the entire data structure content, and update the checksum field of the data header.

[0113] S43. Write the entire contents of the data structure into the predetermined memory area at once.

[0114] In S42 and S43, the NMI interrupt service routine takes the complete software context information captured in S3, including the reconstructed function call history and process stack memory, and fills it as a whole into a specified area after the data header in the data structure. Subsequently, the program calculates a checksum for the entire content from the data header to the end of the data and updates the checksum field in the data header with the result.

[0115] S44. After the data writing is completed, set the status flag bit of the data header to valid to mark that the fault information was successfully stored.

[0116] After all data content has been filled and the checksum has been calculated and written, the program sets the status flag in the data header to a predefined "valid" value. This write sequence design ensures that a data block is only marked as readable after all information has been written to memory completely and without error. If an unexpected power failure occurs during the write process (e.g., during S42 or S43 execution), causing an interruption, the status flag will retain its default "invalid" value. Subsequent diagnostic programs will first check the status flag when reading data; if it is "invalid," the data will be discarded, thus avoiding misinterpretation of incomplete or corrupted data.

[0117] For example, the NMI interrupt service routine can construct this data structure at the starting address of uninitialized RAM. Its status flag is initially set to 0x00000000. The program writes the captured context of main(), Function_A, and Function_B, along with the associated stack memory, into the data structure. Then, it calculates the CRC32 checksum of this content and writes the result to the checksum field. As a final step, the program writes 0x5A5A5A5A to the status flag address as a valid marker. When diagnostic tools subsequently read this area, they first check if the value at the starting address is 0x5A5A5A5A; otherwise, they consider it invalid data. If it is, they further recalculate the CRC32 of the data content and compare it with the stored checksum. Only if the two match will they begin parsing the actual context information.

[0118] S5. After the electronic control unit is reset, the software context information stored in the predetermined memory area is read through the communication interface for use in diagnosing and analyzing software faults.

[0119] In one embodiment, S5 includes: in response to a specific data read request sent by an external diagnostic device via a diagnostic communication protocol, returning the software context information stored in the predetermined memory area as response data.

[0120] The raw software context information read from the ECU is binary memory addresses and data, requiring further parsing to have engineering significance. On an external computer, analysis tools combine the read context information with the symbol information file for the corresponding software version, resolving these raw memory addresses and data into function names, source code line numbers, and variable values ​​that developers can directly analyze. The symbol information file, such as an ELF or DWARF format file, is generated during the software compilation and linking phase. It contains the mapping relationship between all functions and variables in the program and their absolute addresses in memory. Through this mapping, analysis tools can precisely map each return address in the captured function call history to a specific line in the source code and parse the data at a specific address in the process stack memory into specific local variables and their values ​​at the moment of the failure.

[0121] It is important to note that this solution is particularly suitable for low-performance MCUs that are sensitive to cost and resources. Since fault scene capture is primarily automated by hardware, the NMI service program only performs a rapid memory copy, placing extremely low demands on CPU performance and avoiding the need to deploy complex runtime diagnostic protocol stacks within the ECU. For high-performance MCUs, although their processing power is greater, they still cannot solve the fundamental diagnostic challenge of reproducing intermittent faults. Therefore, this solution is also applicable, and by providing a lightweight, highly reliable field capture mechanism, it significantly improves the software debugging efficiency and product quality of all types of ECUs.

[0122] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0123] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A software fault diagnosis method for electronic control units, characterized in that, Includes the following steps: S1. The operating status of the software in the electronic control unit is monitored based on the watchdog timer. When the software fails to reset the watchdog timer within the preset timeout period, a timeout event is generated by the watchdog timer. S2. Trigger a non-maskable interrupt associated with the timeout event based on the timeout event; S3. In response to the non-maskable interrupt, execute the corresponding interrupt service routine to capture the software context information at the time of the fault; S4. Store the software context information in a predetermined memory area whose contents are retained after the electronic control unit is reset; S5. After the electronic control unit is reset, the software context information stored in the predetermined memory area is read through the communication interface for the purpose of diagnosing and analyzing software faults; S3 includes the following sub-steps: S31. Traverse the CSA linked list automatically generated by the processor hardware to capture the function call history; wherein, CSA is the context storage area, and PCXI is the previous context information; the linked list consists of multiple CSA nodes, each CSA node is linked to the previous CSA node through a PCXI pointer, the traversal starts from the current context information pointer and backtracks according to the PCXI pointer stored in each CSA node until the end of the linked list; S32. Based on the stack pointer register value at the time of the fault and the predefined stack boundary information, copy the contents of the corresponding stack memory region to capture the process stack memory; S4 includes the following sub-steps: S41. Construct a data structure containing a predefined data header, wherein the data header is used to encapsulate the software context information, and the data header includes at least a status flag bit for indicating data validity and a checksum for verifying data integrity; S42. Fill the captured software context information into the designated area of ​​the data structure, calculate the checksum of the entire data structure content, and update the checksum field of the data header; S43. Write the entire contents of the data structure into the predetermined memory area at once; S44. After the data writing is completed, set the status flag bit of the data header to valid to mark that the fault information was successfully stored.

2. The software fault diagnosis method for electronic control units according to claim 1, characterized in that, The software context information includes function call history and process stack memory. The function call history is used to record the software execution path before the failure occurred, and the process stack memory is used to store the local variables, parameters and return addresses of the function calls at the time of the failure.

3. The software fault diagnosis method for electronic control units according to claim 2, characterized in that, Each CSA node is a data structure defined by the processor hardware, which includes at least: A PCXI pointer used to link to the previous CSA node; A register field used to store the function's return address, to determine the location in the code where the current function should return after execution; A stack pointer register field is used to store the top of the current stack frame to locate the memory region where local variables and parameters associated with this function call are located; Multiple general-purpose register fields are used to store the processor core's operating state, saving intermediate values ​​for data calculation and processing in the event of a failure.

4. The software fault diagnosis method for electronic control units according to claim 3, characterized in that, S31 includes the following sub-steps: S311. Obtain the entry pointer of the current context automatically saved by the processor hardware when the non-maskable interrupt is triggered, and the entry pointer points to the latest CSA node; S312. Based on the entry pointer, read and record the software context contained in the latest CSA node as the first recording point of the function call history; S313. Extract the stored PCXI pointer from the currently read CSA node; S314. Determine whether the PCXI pointer points to a valid, preceding CSA node address: if yes, jump to the preceding CSA node pointed to by the PCXI pointer and repeat steps S312 and S313; if no, end the traversal. S315. Combine all recorded software contexts in reverse order of traversal backtracking to reconstruct the complete function call history from the initial function call to the point of failure.

5. The software fault diagnosis method for electronic control units according to claim 1, characterized in that, S2 includes the following sub-steps: S21. During the initialization phase of the electronic control unit, configure the interrupt system and set the timeout event of the watchdog timer as a trap request source; S22. Route the service request of the trap request source to the non-maskable interrupt vector of the electronic control unit; S23. Enable the trap corresponding to the non-maskable interrupt to ensure that when the timeout event occurs, any currently executing task can be forcibly interrupted and jump to the preset non-maskable interrupt service routine entry address.

6. The software fault diagnosis method for electronic control units according to claim 1, characterized in that, S5 includes: in response to a specific data read request sent by an external diagnostic device via a diagnostic communication protocol, returning the software context information stored in the predetermined memory area as response data.

7. The software fault diagnosis method for electronic control units according to claim 1, characterized in that, The predetermined memory region is configured as a non-initialized RAM region that skips initialization operations during system startup.

8. The software fault diagnosis method for electronic control units according to claim 1, characterized in that, The non-maskable interrupt has the characteristic that it can still be triggered when global interrupts are disabled or during the execution of other interrupt service routines.

Images