Software fault diagnosis method for electronic control unit

Abstract

The invention relates to a software fault diagnosis method for an electronic control unit, and the method comprises the steps: monitoring the operation state of software in the electronic control unit based on a watchdog timer, and when the software does not reset the watchdog timer within a preset timeout period, starting the watchdog timer; generating a timeout event, triggering a non-maskable interrupt associated with the timeout event, and executing a corresponding interrupt service program to capture software context information at a fault moment; storing the software context information to a predetermined memory area, wherein the content of the software context information is kept after the electronic control unit is reset; and after the electronic control unit is reset, reading the software context information stored in the predetermined memory area through a communication interface. The method has the effect of automatically and reliably capturing the high-value underlying software context information at the moment of fault occurrence under the conditions that a debugger does not need to be physically connected and the fault does not need to be reproduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of automobile control, and in particular to a software fault diagnosis method for an electronic control unit. BACKGROUND

[0002] In the modern automobile industry, as the core component of vehicle systems, the reliability, stability and safety of the software of electronic control units have become the cornerstone of the vehicle safety system. In order to ensure that the electronic control unit can recover to normal when it encounters unexpected software anomalies, such as getting stuck in a dead loop, logic errors or memory access conflicts, etc., leading to program execution flow stagnation, the industry generally uses watchdog timers as a standard system safety mechanism. The watchdog is a hardware timer module, which is periodically reset by the software in the electronic control unit when it is running normally, to show that it is running normally. Once the software fails to respond and fails to reset the timer on time, the watchdog will timeout and forcibly trigger a system hardware reset. This mechanism can effectively recover the electronic control unit from a paralyzed state and ensure the basic functional safety of the vehicle.

[0003] However, although the watchdog reset solves the risk of software continuous freezing, this forced restart process itself can have a significant negative impact on user experience. For example, during driving, the instrument panel may suddenly flash as a whole, some warning lights may be temporarily mis-triggered, or the vehicle information entertainment system may appear a momentary lag or black screen. These phenomena, although short-lived, are enough to cause confusion and concern for the driver, reducing the perceived quality of the product and brand trust. Therefore, automobile manufacturers usually require suppliers to locate and eliminate the root cause of software freezing, rather than relying solely on the watchdog for passive recovery.

[0004] The positioning of the root cause of such software faults that trigger the watchdog is extremely difficult. In the actual road use environment, these software faults often show strong occasionality, and may occur only once in two weeks or even longer, and there is no obvious and traceable trigger rule. This low-frequency and random characteristic makes traditional laboratory debugging methods almost completely ineffective. The development engineer cannot stably reproduce the problem on the bench by connecting the hardware debugger, so he cannot interrupt the program execution when the fault occurs to check the register state and function call stack at that time.

[0005] Another auxiliary means is to pre-embed points in the software, and output a large amount of running logs or tracking information through the communication bus. By analyzing the last printed log before the fault occurs, the approximate execution path of the program can be inferred. But this way itself will affect the running time sequence of the software, which may cause the original sporadic problem to disappear or shift. And at the moment when the system is about to crash, the log output function itself may be abnormal, resulting in incomplete or inaccurate information recorded. In addition, modern vehicles generally support remote diagnosis based on protocols such as unified diagnostic service. But this kind of diagnostic protocol is mainly used for diagnosing known and preset fault scenarios, and is not designed for debugging unknown and catastrophic software program crashes.

[0006] In summary, the prior art lacks a mechanism that can automatically and reliably capture high-value underlying software context information at the moment of fault occurrence without the need for physical connection of a debugger and without the need to reproduce the fault in the process of handling sporadic software lock-up problems of electronic control units. SUMMARY

[0007] In order to be able to automatically and reliably capture high-value underlying software context information at the moment of fault occurrence without the need for physical connection of a debugger and without the need to reproduce the fault, the present application provides a software fault diagnosis method for an electronic control unit.

[0008] The present application provides a software fault diagnosis method for an electronic control unit, which adopts the following technical solution: A software fault diagnosis method for an electronic control unit, comprising the following steps: S1. Monitoring the running state of the software in the electronic control unit based on a watchdog timer, and generating a timeout event by the watchdog timer when the software fails to reset the watchdog timer within a preset timeout period; S2. Triggering a non-maskable interrupt associated with the timeout event based on the timeout event; S3. In response to the non-maskable interrupt, executing a corresponding interrupt service program to capture software context information at the moment of fault; S4. Storing the software context information to a predetermined memory area whose content is maintained after the electronic control unit is reset; S5. After the electronic control unit is reset, reading the software context information stored in the predetermined memory area through a communication interface for diagnostic analysis of software faults.

[0009] By adopting the technical scheme, the timeout event of the watchdog timer is associated with the non-maskable interrupt, and a fault information capturing path which must be executed before the system hardware reset is established. The mechanism uses the hardware characteristic that the non-maskable interrupt cannot be shielded by software, ensures that the capturing action can be reliably triggered when the software is abnormal, and thus solves the technical problem that the traditional watchdog reset directly causes the loss of on-site information. The service program executed in response to the interrupt captures the software context information at the fault time, and stores the software context information in a predetermined memory area whose content can be kept after the reset, so that the key diagnostic information can be preserved across the hardware reset period. After the system is restarted, the software context information stored in the area is read through the communication interface, and thus a data source is provided for remote diagnosis and offline analysis, and the need to reproduce the occasional fault in a laboratory environment is avoided.

[0010] 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 fault occurs, and the process stack memory is used to store local variables, parameters and return addresses of the function call at the time of the fault.

[0011] By adopting the technical scheme, the software context information is specifically defined as including function call history and process stack memory. The function call history is used to restore the software execution path before the fault occurs, and the process stack memory is used to store local variables, parameters and return addresses at the time of the fault. The combination of the two parts of information provides necessary basis for analyzing complex logical errors or data dependency faults, and thus improves the diagnostic capability from simple fault state recording to the level of root cause analysis.

[0012] Optionally, the S3 includes the following sub-steps: S31. Traversing a CSA linked list automatically generated by the processor hardware, so as to capture the function call history; wherein the CSA is a context save area, and the PCXI is previous context information; the linked list is composed of a plurality of 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 backtracking is performed 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 fault time and the predefined stack boundary information, the corresponding stack memory area content is copied to capture the process stack memory.

[0013] By using the above technical solution, the function call history is obtained by traversing the context save area (CSA) linked list automatically generated by the processor hardware, and the previous context information (PCXI) pointer contained in each CSA node is used, so that the interrupt service program can start from the current latest CSA node and perform chain backtracking until the entire call chain is traversed. Meanwhile, by reading the stack pointer register value at the fault time and combining the pre-defined stack boundary information, the stack memory area content directly related to the fault is accurately copied. The two sub-steps decompose the abstract capture action into executable operations based on specific hardware data structures and register states, ensuring the accuracy and integrity of information capture.

[0014] Optionally, each CSA node is a data structure defined by the processor hardware, and the data structure at least includes: a PCXI pointer for linking to a previous CSA node; a register field for storing a function return address to determine the position to which the code should be returned after the current function is executed; a stack pointer register field for storing the top of the current stack frame to locate the memory area where the local variables and parameters related to the function call are located; a plurality of general register fields for storing the processor core working state to save the data calculation and processing intermediate values at the time of fault occurrence.

[0015] By using the above technical solution, the internal data structure of the context save area (CSA) node is limited. By specifying that the data structure must include the PCXI pointer, the return address register field, the stack pointer register field, and the general register field, all basic information units required for reconstructing the fault scene are automatically captured by the hardware from the data source level.

[0016] Optionally, the S31 includes the following sub-steps: S311. Obtain the entry pointer of the current context automatically saved by the processor hardware when triggered by the non-maskable interrupt, 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 PCXI pointer stored in the current read CSA node; S314. Determine whether the PCXI pointer points to a valid, previous CSA node address: if yes, jump to the previous CSA node pointed to by the PCXI pointer and repeat steps S312 and S313; if not, end the traversal; S315. Combining all recorded software contexts in reverse order of the traversal backtracking to reconstruct the complete function call history from the initial function call to the point of failure.

[0017] By adopting the technical scheme, the latest CSA node entry pointer is acquired, current node information is read through a loop and a PCXI pointer is extracted to locate the next node, and finally the backtracking of the entire call chain is completed. After the traversal ends, the recorded context information is reversely sorted and combined to reconstruct the function call history in accordance with the actual execution order.

[0018] Optionally, the S2 comprises the following sub-steps: S21. In the initialization phase of the electronic control unit, configuring an interrupt system, setting the timeout event of the watchdog timer as a trap request source; S22. Routing the service request of the trap request source to a non-maskable interrupt vector of the electronic control unit; S23. Enabling the trap corresponding to the non-maskable interrupt to ensure that when the timeout event occurs, any task currently executed can be forcibly interrupted and jump to a preset non-maskable interrupt service program entry address.

[0019] By adopting the technical scheme, the timeout event of the watchdog is set as the trap request source, the service request thereof is routed to the non-maskable interrupt vector, and finally the trap is enabled, thereby establishing a logical path between the timeout event and the non-maskable interrupt which is guaranteed by hardware.

[0020] Optionally, the S4 comprises the following sub-steps: S41. Constructing a data structure comprising a predefined data header, wherein the data header is used to encapsulate the software context information, and the data header at least comprises a status flag bit used to indicate data validity and a check code used to verify data integrity; S42. Filling the captured software context information into a specified area of the data structure, and calculating a check code of the entire data structure content and updating the check code field of the data header; S43. Writing the entire content of the data structure into the predetermined memory area at one time; S44. After the data writing is completed, setting the status flag bit of the data header as valid to mark that the fault information storage is successful this time.

[0021] By adopting the technical scheme, the context information is encapsulated by constructing a data header containing a state flag bit and a check code, so that the data is ensured to be checkable. In the write operation, the context information is first filled in and the check code is calculated, and after the write of the entire content is completed, the state flag bit is finally set to valid. The design of the write sequence ensures that the external diagnostic device will not read incomplete or damaged data caused by interruption in the write process.

[0022] Optionally, the S5 comprises: In response to a specific data read request sent by the external diagnostic device through a diagnostic communication protocol, the software context information stored in the predetermined memory area is returned as response data.

[0023] Optionally, the predetermined memory area is a non-initialization RAM area configured to skip initialization operation during system startup.

[0024] By adopting the technical scheme, the boot loader or startup code is ensured not to accidentally erase the captured fault data when the system is restarted by configuring it as a non-initialization RAM area that skips initialization operation during system startup.

[0025] Optionally, the non-maskable interrupt has the feature of being able to be triggered during execution of other interrupt service programs or when global interrupts are disabled, to ensure execution of the S3.

[0026] By adopting the technical scheme, the highest level of reliability is provided for execution of the S3 by using the hardware feature of being able to be triggered during execution of other interrupt service programs or when global interrupts are disabled. This feature ensures that the capture action at the fault site can be forcibly executed regardless of the abnormal state in which the software fails.

[0027] Optionally, it further comprises an offline analysis step, which comprises: On the external computer, 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 in combination with the symbol information file of the corresponding software version.

[0028] By adopting the technical scheme, the original 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 can be understood by the developer, which helps to improve the efficiency and accuracy of fault diagnosis. BRIEF DESCRIPTION OF DRAWINGS

[0029] Figure 1 A program block diagram of a software fault diagnosis method for an electronic control unit in an embodiment of the present application is shown.

[0030] Figure 2 A program flow chart illustrating the S1 sub-step in an embodiment of the present application.

[0031] Figure 3 A program flow chart illustrating the S2 sub-step in an embodiment of the present application.

[0032] Figure 4 A schematic diagram illustrating the context save area (CSA) in an embodiment of the present application.

[0033] Figure 5 A program flow chart illustrating the S41 sub-step in an embodiment of the present application.

[0034] Figure 6 A program flow chart illustrating the S4 sub-step in an embodiment of the present application. DETAILED DESCRIPTION

[0035] The present application is further described in connection with the appended drawings in which:

[0036] In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the inventive subject matter. As part of the present disclosure, some of the drawings included herein are set forth in block diagram form to avoid obscuring the inventive subject matter. Some of the details

[0037] Unless specifically stated otherwise, the term "one" and "a" and "the" are not intended to refer to a singular entity but include the general class of which a specific example can be used for illustration. The use of the terms "one" or "a" can mean any number of including "one", "one or more", "at least one", and "one or more than one". The term "or" means any one of the alternatives and any combination of the alternatives, including all of the alternatives, unless the alternatives are expressly indicated to be mutually exclusive. The phrase "at least one of' in combination with a list of items means that at least one of the individual items in the list is present and that any combination of the individual items in the list is also present. The phrase does not require that all of the items in the list be present.

[0038] Automotive Electronic Control Unit, ECU for short, is an embedded system responsible for specific functions in modern vehicles, whose core is a microcontroller MCU. The software program of ECU runs on MCU, controls the actuator to act through a series of complex logic and algorithm operations after reading sensor input, so as to realize functions such as engine management, automatic transmission, vehicle body stability control, etc. To ensure driving safety, a hardware security module, called watchdog timer, is integrated in ECU. When the software is running normally, the timer needs to be reset periodically, which is commonly known as "feeding the dog". If the software stops responding due to a dead loop or other fatal errors, it will not be able to reset the watchdog timer on time, and the timer will trigger a system hardware reset after timeout, so that ECU can recover from the paralyzed state, thereby avoiding the risk caused by continuous software failure.

[0039] However, although the watchdog reset mechanism can restore the function of ECU, the forced restart process itself will cause a series of transient abnormalities, such as instrument panel flickering or vehicle entertainment system lag, which will negatively affect the user experience. Therefore, it is crucial to locate and eliminate the root cause of software deadlock. The reset operation itself will destroy all software context information at the moment of failure, including CPU register state, function call stack and variable value in memory, making it impossible to analyze afterwards.

[0040] Since such software failures often show strong occasionality, they may occur only once in several weeks, and there is no clear recurrence rule. This feature makes the traditional laboratory debugging method, i.e. reproducing and capturing the fault site by connecting a hardware debugger, impractical. To solve this problem, the related technology also tries to pre-embed points in the software, output a large amount of running logs or tracking information through the communication bus. By analyzing the last printed log before the failure occurs, the approximate execution path of the program can be inferred. But this way itself will affect the runtime sequence of the software, which may cause the original occasional problem to disappear or shift.

[0041] Therefore, the embodiments of the present application disclose a software fault diagnosis method for an electronic control unit, referring to Figure 1 , comprising the following steps S1-S5.

[0042] S1. Monitor the running state of the software in the electronic control unit based on the watchdog timer, and generate a timeout event by the watchdog timer when the software fails to reset the watchdog timer within a preset timeout period.

[0043] The watchdog timer monitors the software running state through an internal, continuously incrementing hardware counter. The software of the ECU is designed to periodically write a specific key value to the watchdog module in its main loop or critical task execution path, which is the operation of resetting the watchdog timer, and it will clear the value of the hardware counter. As long as the software execution flow is as expected, it can regularly access the code to reset the timer, so the value of the hardware counter will not accumulate to the preset timeout threshold. Conversely, when the software abnormally occurs, for example, it falls into a dead loop that does not contain the operation of resetting the timer, or it enters an unexpected execution branch due to data errors, the program flow will no longer reach the code to reset the timer. At this time, the hardware counter will continue to accumulate until it exceeds the preset timeout period, which is the generation of a timeout event by the watchdog timer. The timeout event is specifically manifested as a level-flipped signal or a set bit of a specific state register at the hardware level. It needs to be declared that, compared with the related art, the role of the watchdog has fundamentally changed. It is no longer just the final executor of triggering system reset, but has become a high-priority event source for capturing software abnormal state.

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

[0045] In the prior art, the timeout event of the watchdog timer is usually directly connected to the reset controller of the MCU, and its only role is to trigger an unconditional hardware reset. In the present scheme, the timeout event is used as a source for triggering a non-maskable interrupt. The non-maskable interrupt, NMI, is a special type of interrupt in the interrupt system of the microcontroller, which has the highest response priority, and the most critical feature is that it cannot be masked or disabled by software instructions.

[0046] The non-maskable interrupt has the characteristic of being triggered during the execution of other interrupt service programs or when the global interrupt is disabled. When the software executes some critical code segments that have extremely strict timing requirements or need to perform atomic operations, it usually temporarily disables the global interrupt through instructions to prevent its execution process from being interrupted by other ordinary interrupts. Such a code segment is called a critical section. If the software happens to be stuck in such a critical section, all ordinary interrupt requests will be ignored by the hardware. If an ordinary interrupt is used to capture the fault site, the interrupt request will also be masked, resulting in failure to capture and ultimately still leading to direct reset and loss of site information. By using the non-maskable interrupt, regardless of where the software failure occurs, even in a critical section where the global interrupt has been disabled, the fault site capture mechanism of the present scheme can still be enforced.

[0047] To ensure that the captured information is preserved in the event of a subsequent system reset, the present solution requires that the information be stored in a special memory region. Specifically, the predetermined memory region is a non-initializing RAM area that is configured to be skipped during system startup. In the memory space of an ECU, most RAM areas are initialized by a bootloader or startup code after system power-up or reset, typically by being cleared entirely, to ensure that the software starts running from a clean, deterministic state. The predetermined memory region used by the present solution is excluded from this initialization process by being specially declared in the compiler link script. This allows the data content stored in this region to remain unchanged during the hardware reset process triggered by the watchdog. Although skipping the initialization operation means that the memory region can contain indeterminate random values upon first power-up, this can be compensated for by including a validity flag or checksum in the stored data structure, allowing the diagnostic program to distinguish between valid fault capture data and invalid initial values.

[0048] In particular, in an embodiment, with reference to Figure 2 S2 comprises the following sub-steps S21-S23.

[0049] S21. In the initialization phase of the electronic control unit, configure the interrupt system to set the timeout event of the watchdog timer as a trap request source.

[0050] To implement the association trigger described in S2, the interrupt system within the MCU is configured in the software initialization phase of the ECU, where the interrupt system is the core logic unit responsible for managing and distributing all interrupt requests in the MCU. First, the timeout event of the watchdog timer is set as a trap request source. A trap is a type of service request generated directly by a hardware module, similar to a normal interrupt request, but typically used to handle more low-level system events. This step logically identifies the watchdog timeout signal as an allocatable service request source by writing a predefined value to a specific configuration register of the interrupt system.

[0051] S22. Route the service request of the trap request source to a non-maskable interrupt vector of the electronic control unit.

[0052] Routing here refers to establishing a logical path from the request source to a specific processing unit within the interrupt system. The interrupt system of MCU usually contains a programmable routing mechanism, allowing developers to direct different interrupt or trap sources to different processing cores or interrupt vectors. The non-maskable interrupt vector is a specific address in memory that is predefined and stores the entry address of the non-maskable interrupt service program. This step logically connects the trap request source set in S21 with the non-maskable interrupt vector by configuring the relevant routing register.

[0053] S23. Enable the trap corresponding to the non-maskable interrupt to ensure that when the timeout event occurs, any task currently being executed can be forcibly interrupted and jump to the preset entry address of the non-maskable interrupt service program.

[0054] Enable means to activate the configured interrupt path and put it on standby. This step is completed by setting a specific control bit in the CPU or interrupt controller. Once enabled, the interrupt system will start listening to the trap request. When the watchdog timer generates a timeout event, the event will be captured and confirmed as a valid non-maskable interrupt request along the path established by S21 and S22, thus forcing the CPU to interrupt any task currently being executed and unconditionally jump to the preset entry address of the non-maskable interrupt service program to start execution.

[0055] Taking 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 timeout request of the watchdog timer as 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, thus completing the entire configuration process.

[0056] S3. In response to the non-maskable interrupt, execute the corresponding interrupt service program to capture the software context information at the time of failure. 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 occurs, and the process stack memory is used to store the local variables, parameters and return addresses of function calls at the time of failure.

[0057] The core task of the interrupt service routine is to take a snapshot of the fault site, and the function call history and the process stack memory are two key dimensions of the snapshot. The function call history provides the macroscopic path information of program execution. For example, a software fault may occur in such a scenario: the main function main() calls the module initialization function Module_A_Init(), which in turn calls the underlying driver function Driver_B_Write(), and finally falls into a dead loop due to an invalid pointer access in the Driver_B_Write() function. At this time, the function call history is represented as a call chain main()->Module_A_Init()->Driver_B_Write(). The process stack memory provides microscopic data information of the fault point. In the foregoing example, the process stack memory contains the local variables of the Driver_B_Write() function itself, the argument values passed to it by the Module_A_Init(), and the code address to which Driver_B_Write() should return after execution.

[0058] In particular, in an embodiment, with reference to Figure 3 S3 comprises the following sub-steps S31-S32.

[0059] S31. Traversing the CSA linked list automatically generated by the processor hardware to capture the function call history; wherein CSA is the context save area, and PCXI is the previous context information; the linked list is composed of multiple CSA nodes, each CSA node is linked to the previous CSA node through a PCXI pointer, and 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.

[0060] S32. Based on the stack pointer register value at the fault time and the pre-defined stack boundary information, copying the corresponding stack memory area content to capture the process stack memory.

[0061] Context Save Area (CSA) is a special area in memory created by the processor hardware automatically when a function call or an interrupt occurs, which is used to save the key register information of the current execution environment. Previous Context Information (PCXI) is a special pointer stored in each newly created CSA, which points to the address of the previous CSA, thus linking multiple CSAs into a linked list reflecting the calling sequence. Stack Pointer Register (SPR) is a special register in CPU, whose content is the top address of the stack memory area used by the current process. Stack Boundary Information (SBI) refers to the start and end addresses of the stack space pre-allocated for each task or process in the software design phase. Stack Memory Area (SMA) is the content stored in the boundary range. Process Stack Memory (PSM) is the overall reference to the content of the area.

[0062] Both function call history and process stack memory are indispensable for fault diagnosis. With only the function call history, the analyst can only know which function the program has executed to, but cannot know what kind of abnormal data or parameters caused the fault to occur. Conversely, with only the process stack memory, the analyst can see the instantaneous data at the fault point, but due to the lack of calling path information, cannot trace back how these abnormal data were generated, nor can understand why the program executed to the current state. Therefore, both must be combined to completely reconstruct the fault scene, so as to effectively analyze the root cause.

[0063] Specifically, referring to Figure 4 Each CSA node is a data structure defined by the processor hardware, which at least includes: a PCXI pointer for linking to the previous CSA node; a register field for storing the function return address to determine the location to which the code should return after the current function is executed; a stack pointer register field for storing the top of the current stack frame to locate the memory area where the local variables and parameters related to this function call are located; a plurality of general register fields for storing the working state of the processor core to save the intermediate values of data calculation and processing at the time of fault occurrence.

[0064] The data structure provides a comprehensive snapshot of the software state at the moment of fault. Among them, the PCXI pointer for linking to the previous CSA node is the basis for building and traversing the call chain, which connects discrete context snapshots like a chain. The register field for storing the function return address usually saves the content of the program counter or return address register, which clearly shows the hierarchical relationship and return path of the function call.

[0065] Continuing with the example, when the software execution fails inside the Driver_B_Write() function, the hardware automatically generates a corresponding CSA node. In this CSA node, the PCXI pointer field stores the memory address of the CSA node corresponding to the Module_A_Init() function. The return address register field stores the address of the instruction in the Module_A_Init() function to which the execution of the Driver_B_Write() function should return after it finishes. The stack pointer register field stores the top address of the current stack frame, from which the local variables of the Driver_B_Write() function and the parameters passed to it by the Module_A_Init() function can be indexed. In addition, the general register fields for storing the working state of the processor core store the instantaneous values of all the data registers and address registers in the CPU at the time of the failure, such as the address value of the invalid pointer that caused the endless loop, or the value of the key variable that caused the calculation error, which are all fixed in these fields.

[0066] Figure 4 The process of the processor hardware automatically packing and saving the internal state, i.e. the register contents, in a linked list form in the memory when a function call or an interrupt occurs is shown. The context save area (CSA) shown in the figure is a structured block in the memory, used to store the snapshot of the CPU core registers at a certain moment. According to the type of context switching, the hardware automatically saves different sets of registers, such as the set of context registers when a function call occurs, and the set of context registers when an interrupt or trap occurs. At the end of each CSA memory block, there is a key PCXI field, which stores not ordinary data, but the memory address of the previous CSA block. It is this PCXI pointer that links the individual CSA blocks in the memory to form a unidirectional linked list that reflects the call sequence, which is automatically maintained by the hardware.

[0067] With the above example of program execution flow, when the main() function calls Function_A, the hardware creates a first CSA block in memory to save the context of main(), and the PCXI pointer in this CSA block is empty. Then, when Function_A calls Function_B, the hardware creates a new CSA block to save the context of Function_A, and the PCXI pointer in this new CSA block points to the address of the first CSA block saved for the main() function. If a software hang-up occurs in Function_B at this time, causing the watchdog to time out and trigger an NMI, the hardware creates a third CSA block to save the context of Function_B at the moment of the hang-up, and the PCXI pointer in this latest CSA block points to the CSA block address of Function_A. In this way, a complete call chain is formed for back-tracing analysis.

[0068] In particular, in an embodiment, referring to Figure 5 , the S31 comprises the following sub-steps S311-S315.

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

[0070] To achieve the capture of the function call history, the NMI interrupt service program executes a specific back-tracing algorithm. In S311, when the interrupt service program starts executing, it first obtains the entry pointer of the current context from a specific system register of the CPU. The pointer is automatically filled in by the processor hardware in response to the NMI, and its value is the memory address of the latest CSA node created to save the context at the moment of the fault.

[0071] 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.

[0072] S313. Extract the PCXI pointer stored in the currently read CSA node.

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

[0074] In S314, the program judges the extracted PCXI pointer. If the pointer is a non-empty valid address, it proves that there is a previous caller in the calling chain. The program takes the PCXI pointer as a new target address, jumps to the previous CSA node pointed by the address, and repeats the reading record operation in S312 and the extracting PCXI pointer operation in S313. This process will continue until the extracted PCXI pointer in a CSA node is empty or points to a predefined end-of-list marker, at which time the program judges that the most initial node of the calling chain has been reached, and the traversal process ends.

[0075] S315. Combining all the recorded software contexts in the reverse order of the traversal backtracking, thereby reconstructing the complete function call history from the initial function call to the fault occurrence point.

[0076] Continuing with the example of the above program execution flow, the entry pointer obtained in S311 points to the CSA node generated when Function_B is stuck. S312 records the context of Function_B. S313 extracts the PCXI pointer pointing to the CSA node corresponding to Function_A. S314 judges that the 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 judges again that the pointer is valid, then jumps and repeats the operation, records the context of main(), and extracts the PCXI pointer thereof, at which time the pointer is empty, and the traversal ends.

[0077] Finally, in S315, the program reversely orders and combines the series of context information recorded in the execution order of S312 to S314, i.e., the context of Function_B, the context of Function_A, and the context of main(). Through this step, the complete function call history from the initial function call to the fault occurrence point, i.e., main()->Function_A()->Function_B(), which is completely consistent with the actual execution flow, is finally reconstructed.

[0078] S4. Storing the software context information to a predetermined memory area whose content is maintained after the electronic control unit is reset.

[0079] Specifically, in an embodiment, with reference to Figure 6 S4 includes the following sub-steps S41-S44.

[0080] 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 at least includes a status flag indicating data validity and a check code for verifying data integrity.

[0081] A predefined data structure is first constructed in the non-initialized RAM area. The first end of the data structure is a data header, which serves as metadata to describe the software context information following it. The data header at least contains two key fields: one is a status flag, which is a memory cell with a specific value, indicating whether the currently stored data is complete and valid; the other is a check code, such as a cyclic redundancy check code (CRC), which is a numerical value calculated from the actual bit value of the data content by a specific algorithm, used to verify whether the data has been damaged during storage when read.

[0082] S42. Fill the captured software context information into the designated area of the data structure, and calculate the check code of the entire data structure content, updating to the check code field of the data header.

[0083] S43. Write the entire content of the data structure to the predetermined memory area at once.

[0084] In S42 and S43, the NMI interrupt service program fills the complete software context information captured in S3, including the reconstructed function call history and process stack memory, into the designated area of the data structure after the data header as a whole data block. Then, the program calculates the check code of the entire content from the data header to the end of the data, and updates the calculation result to the check code field of the data header.

[0085] S44. After the data is written, set the status flag of the data header to valid to mark the successful storage of this fault information.

[0086] After filling all the data content and calculating and writing the check code, the program sets the status flag of the data header to a predefined "valid" value. The design of this write sequence ensures that only when all information has been written to the memory completely and correctly, the data block will be marked as available for reading. If an unexpected power drop occurs during the writing process (e.g. during the execution of S42 or S43), the status flag will remain its default "invalid" value. The subsequent diagnostic program will first check the status flag when reading the data, and if it is "invalid", the data will be discarded directly, thereby avoiding the misinterpretation of incomplete or damaged data.

[0087] For example, the NMI interrupt service routine can build this data structure at the start address of the non-initialized RAM. Its status flag is initially set to 0x00000000. The routine writes the captured contexts of main(), Function_A, Function_B, and the associated stack memory into the data structure. Then it calculates the CRC32 checksum of this part of the content and writes the result into the checksum field. As the last step, the routine writes 0x5A5A5A5A into the status flag address as a valid marker. When the diagnostic tool reads this area later, it first checks the value at the start address, and if it is not 0x5A5A5A5A, it considers there is no valid data; if it is, it further recalculates the CRC32 of the data content and compares it with the stored checksum. Only if they are the same, it starts to parse the real context information.

[0088] S5. After the electronic control unit is reset, the software context information stored in the predetermined memory area is read through a communication interface for diagnostic analysis of software faults.

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

[0090] The original software context information read from the ECU is binary memory addresses and data, which needs further parsing to have engineering significance. On an external computer, the analysis tool will combine the read context information with the corresponding software version symbol information file to parse these original memory addresses and data into function names, source code line numbers, and variable values that can be directly analyzed by developers. The symbol information file, such as the ELF or DWARF format file, is generated during the software compilation and linking stage, and it contains the mapping relationship between all functions, variables in the program and their absolute addresses in memory. Through this mapping, the analysis tool can accurately correspond each return address in the captured function call history to a 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 fault moment.

[0091] It should be noted that this scheme is particularly suitable for low-performance MCUs which are sensitive to cost and resources. Since the capture action of the fault site mainly relies on automatic completion of hardware, the NMI service program only performs a fast memory copy, and the performance requirement of the CPU is extremely low, avoiding the deployment of a complex runtime diagnostic protocol stack in the ECU. For high-performance MCUs, although their processing capability is stronger, they are still unable to solve the fundamental diagnostic problem of the difficulty in reproducing occasional faults, and therefore this scheme is also applicable. By providing a lightweight and highly reliable on-site capture mechanism, the software debugging efficiency and product quality of all types of ECUs are significantly improved.

[0092] It should be understood that the size of the serial number of each step in the above embodiments does not mean the order of execution, and the execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0093] The above embodiments are only used to illustrate the technical solutions of the present application, but not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can still be modified, or some technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A software failure diagnosis method for an electronic control unit, characterized by, The method comprises the following steps: S1. monitoring the running state of software in the electronic control unit based on a watchdog timer, and generating a timeout event by the watchdog timer when the software fails to reset the watchdog timer within a preset timeout period; S2. triggering a non-maskable interrupt associated with the timeout event based on the timeout event; S3. in response to the non-maskable interrupt, executing a corresponding interrupt service program to capture software context information at the time of failure; S4. storing the software context information in a predetermined memory area whose content is maintained after the electronic control unit is reset; S5. after the electronic control unit is reset, reading the software context information stored in the predetermined memory area through a communication interface for diagnostic analysis of software failure.

2. The software failure diagnosis method for an electronic control unit according to claim 1, characterized by, The software context information comprises function call history and process stack memory, wherein the function call history is used to record the software execution path before failure, and the process stack memory is used to store local variables, parameters and return addresses of function calls at the time of failure.

3. The software failure diagnosis method for an electronic control unit according to claim 2, characterized by, The S3 comprises the following sub-steps: S31. traversing a CSA linked list automatically generated by processor hardware to capture function call history; wherein CSA is a context save area, PCXI is previous context information; the linked list is composed of a plurality of CSA nodes, each CSA node is linked to a previous CSA node through a PCXI pointer, the traversal starts from a current context information pointer and backtracks according to the PCXI pointer stored in each CSA node until the end of the linked list; S32. copying the content of the corresponding stack memory area based on the stack pointer register value at the time of failure and the predefined stack boundary information to capture the process stack memory.

4. The software failure diagnosis method for an electronic control unit according to claim 3, characterized by, Each CSA node is a data structure defined by processor hardware, which at least comprises: a PCXI pointer for linking to a previous CSA node; a register field for storing a function return address to determine the position of the code to which the current function should return after execution; a stack pointer register field for storing the top of the current stack frame to locate the memory area of local variables and parameters related to the function call; a plurality of general register fields for storing processor core working states to save intermediate values of data calculation and processing at the time of failure.

5. The software failure diagnosis method for an electronic control unit according to claim 4, characterized by, The S31 comprises the following sub-steps: S311. obtaining an entry pointer of the current context automatically saved by the processor hardware when triggered by the non-maskable interrupt, the entry pointer pointing to the latest CSA node; S312. based on the entry pointer, reading and recording the software context contained in the latest CSA node as the first recording point of the function call history; S313. extracting the PCXI pointer stored in 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 by the PCXI pointer, and repeat steps S312 and S313; if no, end the traversal; S315. Combine all recorded software contexts in the reverse order of the traversal, to reconstruct the complete function call history from the initial function call to the fault occurrence point.

6. The software failure diagnosis method for an electronic control unit according to claim 1, characterized by, The S2 comprises the following sub-steps: S21. In the initialization phase of the electronic control unit, configure the interrupt system, 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 task currently executing can be forcibly interrupted, and jump to the preset non-maskable interrupt service program entry address.

7. The software failure diagnosis method for an electronic control unit according to claim 1, characterized by, The S4 comprises 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 at least includes a status flag bit for indicating data validity and a check code for verifying data integrity; S42. Fill the captured software context information into the specified area of the data structure, and calculate the check code of the entire data structure content, and update to the check code field of the data header; S43. Write the entire content of the data structure to the predetermined memory area at one time; S44. After the data is written, set the status flag bit of the data header to valid to mark the success of this fault information storage.

8. The software failure diagnosis method for an electronic control unit according to claim 1, characterized by, The S5 comprises: In response to a specific data read request sent by an external diagnostic device through a diagnostic communication protocol, return the software context information stored in the predetermined memory area as response data.

9. The software failure diagnosis method for an electronic control unit according to claim 1, characterized by, The predetermined memory area is configured as a non-initialization RAM area that skips initialization operation during system startup.

10. The software failure diagnosis method for an electronic control unit according to claim 1, characterized by, The non-maskable interrupt has the feature of being able to be triggered when global interrupts are disabled or during execution of other interrupt service programs.

Images