Motor controller hardware Trap data acquisition method and system and electronic equipment

Abstract

The invention provides a motor controller hardware Trap data acquisition method and system and electronic equipment, and relates to the field of electric vehicle control. The method comprises the following steps: periodically collecting key operation parameters of a motor controller, and caching the key operation parameters to an RAM (Random Access Memory); in response to a hardware Trap trigger event of the electric control chip, acquiring state information of a peripheral register and program state information of the electric control chip, generating a Trap data snapshot containing a Trap event identifier and a system state snapshot, and extracting key operation parameters in preset durations before and after the occurrence of the hardware Trap trigger event from an RAM (Random Access Memory) as context key parameters; storing the Trap data snapshots and the context key parameters into a ring memory; and in response to a data uploading trigger condition, reading the data from the annular memory and uploading the data to a target server. According to the scheme, data related to the hardware Trap can be efficiently collected and recorded so as to restore a complete fault scene.

Description

Technical Field

[0001] This application relates to the field of electric vehicle control, and more specifically, to a method, system, and electronic device for acquiring hardware trap data for a motor controller. Background Technology

[0002] As the market share of new energy vehicles increases, the functional design of motor controllers is becoming increasingly complex. Consequently, their core electronic control chips are more prone to triggering hardware traps under complex operating conditions, such as illegal instructions and memory access errors.

[0003] Taking widely used electronic control chips as an example, their hardware trap mechanisms include various categories and subcategories. For instance, a common error like accessing a null pointer will trigger a trap of the corresponding category and subcategory. However, in existing technologies, when such a hardware trap occurs, the system typically only records very limited trap information (such as the trap category and trigger address) and then immediately performs a reset operation. The hardware trap mechanism, in contrast, is a mandatory interrupt protection mechanism automatically triggered by the electronic control chip hardware when it detects serious anomalies such as illegal instructions or memory access errors.

[0004] Under this method of collecting and recording Trap information, the fault occurrence scenario is often difficult to reconstruct effectively, severely hindering subsequent problem analysis and localization. Therefore, the existing method of collecting and recording hardware Trap data for motor controllers can no longer meet the urgent needs of the new energy vehicle industry for accurate and efficient fault diagnosis of motor controllers. Summary of the Invention

[0005] The purpose of this application is to provide a method, system, and electronic device for acquiring hardware trap data of a motor controller, which can efficiently acquire and record data related to the hardware trap, thereby enabling the reconstruction of complete fault scenarios and meeting the urgent need of the new energy vehicle industry for accurate and efficient fault diagnosis of motor controllers.

[0006] This application is implemented as follows: In a first aspect, this application provides a method for acquiring hardware trap data of a motor controller, comprising the following steps: periodically acquiring key operating parameters of the motor controller and caching them in random access memory; in response to a hardware trap trigger event of the electronic control chip, acquiring peripheral register status information and program status information of the electronic control chip, generating a trap data snapshot containing a trap event identifier and a system status snapshot, and extracting the key operating parameters within a preset time period before and after the occurrence of the hardware trap trigger event from the random access memory to obtain context key parameters; storing the trap data snapshot and context key parameters in a ring memory; and in response to a data upload trigger condition, reading the trap data snapshot and context key parameters from the ring memory and uploading them to a target server.

[0007] Secondly, this application provides a motor controller hardware trap data acquisition system, which includes: The Trap monitoring module is configured to: periodically collect key operating parameters of the motor controller and cache them in random access memory; and, in response to a hardware Trap trigger event of the electronic control chip, acquire peripheral register status information and program status information of the electronic control chip, generate a Trap data snapshot containing a Trap event identifier and a system status snapshot, and extract the key operating parameters within preset time periods before and after the occurrence of the hardware Trap trigger event from the random access memory to obtain context key parameters. The ring storage module is configured to: store the Trap data snapshot and context key parameters sent by the Trap monitoring module. The XCP slave module is configured to: in response to a data upload trigger condition, read the Trap data snapshot and context key parameters from the ring storage module and upload them to the target server.

[0008] Thirdly, this application provides an electronic device including a memory for storing one or more programs; a processor; and, when the one or more programs are executed by the processor, implementing the method as described in any one of the first aspects above.

[0009] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in any one of the first aspects above.

[0010] Fifthly, this application provides a computer program product including computer program instructions that, when executed by a processor, implement the method as described in any one of the first aspects above.

[0011] Compared with the prior art, this application has at least the following advantages or beneficial effects: This application first periodically collects and caches key operating parameters of the motor controller, dynamically maintaining a real-time window of these key operating parameters in random access memory. When the control chip triggers a hardware Trap event, it performs two key operations synchronously or asynchronously: first, it immediately captures the program state and peripheral register state inside the control chip, obtaining a snapshot of the fault moment (Trap data snapshot); second, it extracts key operating parameters from the cache within a preset time period before and after the event, forming a fault context (context key parameters). These two sets of data are then stored together in a ring memory. Finally, when the data upload trigger condition is met, the data stored in the ring memory is encrypted and uploaded to the target server.

[0012] Thus, by associating a snapshot of the fault moment with the fault context, this application fully reproduces the state of the electronic control chip and external operating conditions at the time of the fault, greatly improving the accuracy and depth of remote fault diagnosis and helping to locate complex and intermittent problems. Secondly, the ring storage and condition-triggered upload mechanism optimizes local storage space utilization and saves communication resources while ensuring that critical data is not lost, making the remote aggregation and analysis of all fault data feasible. Furthermore, combined with condition-triggered upload, it effectively avoids the bottleneck of insufficient bandwidth (peak <500kbps) of the traditional CAN bus, transmitting data only when network conditions permit or when necessary, thereby significantly saving communication resources. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 This is a flowchart of an embodiment of a hardware trap data acquisition method for a motor controller according to this application; Figure 2 This is a flowchart illustrating the specific steps of encrypting and uploading to the target server in this embodiment of the application. Figure 3 This is a structural block diagram of an embodiment of a motor controller hardware trap data acquisition system according to this application; Figure 4 This is a structural block diagram of an electronic device provided in an embodiment of this application.

[0015] Icons: 101, Trap monitoring module; 102, ring storage module; 103, XCP slave module; 201, processor; 202, memory; 203, communication interface. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0017] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0018] Application Overview In developing this application, the inventors recognized that existing technologies only record limited internal chip information (such as trap type and address) after a hardware trap occurs, and then immediately reset the system. This approach essentially loses the "scene environment" of the fault, meaning that the complete system state and operating environment data (such as key parameters like current, voltage, and speed) at the moment the trap occurs cannot be effectively recorded and preserved, resulting in the inability to fully reconstruct the fault scenario and severely limiting diagnostic accuracy.

[0019] To address the aforementioned technical issues, this application provides a method for acquiring hardware trap data in a motor controller. This method continuously and asynchronously acquires and caches key system parameters before a trap occurs, creating a dynamically updated "time window." When a hardware trap event is triggered, it not only instantly captures the chip's internal program state and hardware register snapshots, forming a precise "fault snapshot," but also immediately extracts key operating parameters from the cache for a period before and after the event trigger, forming a "fault context." Finally, these two are correlated and reliably stored, providing a data package containing a complete timeline and system state for fault analysis. This enables efficient acquisition and recording of hardware trap-related data, allowing for the reconstruction of complete fault scenarios and meeting the urgent need of the new energy vehicle industry for accurate and efficient fault diagnosis of motor controllers.

[0020] After introducing the basic principles of this application, various non-limiting embodiments of this application will be described in detail below with reference to the accompanying drawings. Unless otherwise specified, the various embodiments and features described below can be combined with each other.

[0021] Exemplary methods Please see Figure 1 The method for acquiring hardware trap data from a motor controller includes the following steps: Step S101: Periodically collect key operating parameters of the motor controller and cache them in random access memory.

[0022] In step S101 above, key operating parameters of the motor controller (such as three-phase current, DC bus voltage, motor speed, IGBT temperature, etc.) are actively collected at fixed time intervals (e.g., milliseconds or microseconds). This data, representing the real-time operating status of the motor controller, is not used immediately or permanently stored, but is continuously written to a pre-defined buffer in random access memory (RAM). This buffer can be designed as a circular queue (FIFO) structure, where new data continuously overwrites old data, thus maintaining a recent, fixed-time dynamic data window (e.g., data from the last 10 seconds or 100 milliseconds) in RAM.

[0023] For example, key electronic control parameters, such as current, voltage, speed, and temperature, totaling 32 parameters, can be collected in 100µs intervals. The data collected every 100µs is stored as a single data set in RAM, with a maximum cache of 100 data sets, or 10ms of data. This 100µs interval captures changes in the electronic control parameters within a short timeframe, preventing the loss of instantaneous changes in these parameters.

[0024] Compared to attempting to record lost transient data only after a fault occurs, step S101 fundamentally ensures the availability of key environmental parameters before and after the fault. Furthermore, by utilizing the high-speed read and write characteristics of RAM, it has minimal impact on the performance of the main control loop, enabling seamless data acquisition.

[0025] Please continue reading. Figure 1 Step S102: In response to the hardware Trap trigger event of the electronic control chip, obtain the peripheral register status information and the program status information of the electronic control chip, generate a Trap data snapshot containing the Trap event identifier and the system status snapshot, and extract the key operating parameters within each preset time period before and after the occurrence of the hardware Trap trigger event from the random access memory to obtain the context key parameters.

[0026] When the electronic control chip triggers a hardware trap event due to an anomaly (such as illegal memory access or computational error), it will immediately preempt CPU resources for a rapid response. First, it can preemptively capture peripheral register status information and the electronic control chip's program status information, generating a system state snapshot accurate to the instruction level. Preemption is a processor scheduling method used by the operating system, its core feature being that it allows the system to forcibly interrupt the currently running process and allocate processor resources to a higher-priority ready process. Simultaneously, combined with trap source information (diagnostic root cause data such as category and address recorded when the hardware trap is triggered), a snapshot data packet containing an event identifier (the data packet corresponding to the trap data snapshot) is formed.

[0027] In other words, when a hardware Trap event is triggered, the system immediately freezes and reads the current values ​​of the registers in the CPU core (program counter PC, stack pointer SP, function call stack) and peripheral modules (PWM, ADC, etc.). These instantaneous state values ​​are then aggregated into a single packet, creating a complete data record that accurately reflects the chip's internal state at the moment of the fault—a system state snapshot. Simultaneously, this "system state snapshot" is used as the core data body, combined with Trap source information describing the anomaly (including Trap classification and subclass number), and assembled and encapsulated according to a preset fixed format (as exemplified by the 208-byte structure below). Finally, a standard data packet containing both a complete state snapshot and a clear fault identifier is generated—a Trap data snapshot. The assembly and encapsulation according to the preset fixed format refers to the process of sorting, assembling, and packaging various scattered Trap-related data into a single data unit based on a predefined structural template.

[0028] Next, using the Trap trigger moment as the time origin, all key operating parameters cached within a preset time period (e.g., 10ms before and 10ms after) before and after that moment are precisely extracted from the RAM cache maintained in step 101. The combination of the Trap data snapshot and the context key parameters constitutes a complete dataset describing this fault. It should be noted that the preset time period before and after is generally much longer than the period for collecting key operating parameters of the motor controller (generally more than an order of magnitude) to ensure that cached key operating parameters definitely exist within the preset time period before and after.

[0029] System status snapshots pinpoint exactly "where and how" the software and hardware malfunctioned, while context parameters fully reveal "what the system was doing and under what conditions" at the time of the failure. The combination of these two provides a comprehensive view of the incident for fault analysis, making it possible to reproduce sporadic, deep-seated software defects or hardware edge problems related to complex operating conditions.

[0030] In other words, by periodically collecting and caching key operating parameters and extracting key operating parameters from the time periods before and after a trap is triggered, a dynamic and continuous cache of the electronic control chip's operating status is established. When a trap occurs, this cache can provide the "antecedent" (such as the trend of abnormal parameter changes) and "consequence" (such as the electronic control chip's response after the trap) of the trap, so that subsequent analysis is no longer limited to the trap point itself, but has a complete trap context.

[0031] Please continue reading. Figure 1 Step S103: Store the Trap data snapshot and context key parameters into a ring memory.

[0032] It's important to note that while conventional linear memory requires external intervention or discarding new data once it's full, circular memory, through its end-to-end cyclic overwrite mechanism, achieves perpetual updating within a limited space. This ensures that the latest fault data is always recorded throughout the vehicle's entire lifecycle, eliminating the need for manual maintenance. Furthermore, its cyclic overwrite characteristic naturally enables automatic scrolling of the data time window, always retaining the most recent and relevant fault records, making it particularly suitable for applications such as diagnosing intermittent faults.

[0033] Step S104: In response to the data upload trigger condition, read the Trap data snapshot and context key parameters from the ring memory and upload them to the target server.

[0034] In step S104 above, the reporting of Trap data snapshots and contextual key parameters to the target server is not triggered in real time, but is driven by preset conditions (such as the vehicle entering the garage and connecting to Wi-Fi, the arrival of a regular maintenance cycle, or the issuance of remote diagnostic commands), which can significantly save on in-vehicle communication bandwidth and data costs. When the conditions are met, the specified fault data record (the specified Trap data snapshot and contextual key parameters) will be read from the ring memory, encrypted (e.g., using the AES algorithm) and integrity verified (e.g., by adding a CRC code), and then transmitted to the remote target server via the in-vehicle network (e.g., Ethernet, 5G).

[0035] In summary, this application first dynamically maintains a real-time window of key operating parameters in random access memory through periodic data acquisition and caching. When the electronic control chip triggers a hardware Trap event, it performs two key operations synchronously or asynchronously: first, it immediately captures the program state and peripheral register state inside the electronic control chip to obtain a snapshot of the fault moment (Trap data snapshot); second, it extracts key operating parameters from the cache within a preset time period before and after the event, forming a fault context (context key parameters). These two sets of data are then stored together in a ring memory. Finally, when the data upload trigger condition is met, the data stored in the ring memory is encrypted and uploaded to the target server.

[0036] Thus, by associating a snapshot of the fault moment with the fault context, this application fully reproduces the state of the electronic control chip and external operating conditions at the time of the fault, greatly improving the accuracy and depth of remote fault diagnosis and helping to locate complex and intermittent problems. Secondly, the ring storage and condition-triggered upload mechanism optimizes local storage space utilization and saves communication resources while ensuring that critical data is not lost, making the remote aggregation and analysis of all fault data feasible. Furthermore, combined with condition-triggered upload, it effectively avoids the bottleneck of insufficient bandwidth (peak <500kbps) of the traditional CAN bus, transmitting data only when network conditions permit or when necessary, thereby significantly saving communication resources.

[0037] Based on the aforementioned scheme, in some implementations of this application, the step of periodically collecting key operating parameters of the motor controller and caching them to random access memory includes: periodically collecting key operating parameters of the motor controller; performing data conversion and structured encapsulation on the collected key operating parameters according to a preset data parsing table to generate data units containing parameter category codes, data type codes, data lengths, and converted values, wherein the data parsing table defines the mapping relationship between parameter category codes, data type codes, data lengths, and data conversion rules for each key operating parameter; and caching the data units to random access memory.

[0038] In the above implementation, a data conversion and structured encapsulation mechanism based on a data parsing table is introduced. After periodically collecting key operating parameters, the raw data is not stored directly. Instead, each parameter is converted and encapsulated into a standard data unit containing encoding, type, length, and value according to a predefined parsing table. For example, to facilitate rapid data parsing, a 2-byte encoding and a 1-byte data type encoding can be assigned to each parameter category. During storage, the parameter encoding, data type encoding, length, conversion result, and other information are stored. For example, when storing the U-phase current -32.456 A, "A0 01 01 04 C2 01 D2 F1" will be stored, totaling 8 bytes of data. The cloud server will also parse the received data according to the data parsing table. For example, upon receiving "A0 03 02 01 2D", the table shows that the parameter is module temperature, the data type is UINT8, the length is 1 byte, and the value is 45℃.

[0039] This data parsing table can be stored as a configuration file on both the vehicle and cloud platforms. When it's necessary to delete, add, or modify collected parameters, only the data parsing table needs to be maintained. The vehicle or cloud platform will then collect or parse data based on the latest data parsing table, effectively improving system maintainability and reducing system maintenance costs.

[0040] In other words, the above implementation method can effectively improve data standardization and system maintainability: On the one hand, the data parsing table, as a unified data dictionary, ensures consistency in the understanding of data meaning and format between the vehicle and the cloud, enabling the original sampled values ​​(such as floating-point numbers) to be accurately parsed and reconstructed after passing through standard conversion rules (such as hexadecimal conversion). This fundamentally solves the ambiguity or errors that may occur in the acquisition, storage, transmission, and parsing stages of heterogeneous data. On the other hand, separating the specific definition of parameters (such as adding a temperature sensor) from the acquisition / parsing logic allows system adjustments to be completed simply by updating the data parsing table configuration file. This significantly reduces the development and maintenance costs caused by parameter set changes and enhances the system's adaptability and flexibility when facing different controller configurations or functional iterations.

[0041] For example, the data parsing table can be shown in the following table:

[0042] Based on the aforementioned scheme, in some implementations of this application, the structured encapsulation includes: for each key operating parameter, arranging the parameter category code, data type code, data length, and converted numerical code in sequence to obtain the corresponding encapsulated data; and sequentially concatenating the encapsulated data of multiple key operating parameters to obtain the corresponding data unit.

[0043] In the above implementation, a self-describing standardized data block is constructed for each key operating parameter: the parameter category code (identifying the parameter's identity), data type code (specifying the data format), data length (determining the space occupied by the value), and the converted value code (carrying the actual data) are arranged in a fixed order. Subsequently, multiple such independent data blocks are sequentially concatenated to form a complete data unit.

[0044] Thus, because each data block carries complete metadata (category, type, length), data units can be parsed independently and accurately even without external context. This self-describing characteristic greatly enhances data portability and reliability. Secondly, the standardized arrangement provides determinism to the parsing process, allowing the receiver (such as a cloud server) to perform efficient streaming parsing based on the known structure, eliminating the need for complex format detection or dynamic matching, thereby significantly reducing computational overhead and improving data processing speed. This design ensures that massive amounts of parameter data can be efficiently and error-free serialized and deserialized between resource-constrained vehicle terminals and high-concurrency cloud environments.

[0045] Based on the aforementioned scheme, in some implementations of this application, the program state information includes at least one of the following: function call stack data, Trap category number and Trap subclass number corresponding to the hardware Trap trigger event, the current value of the program counter PC, or the current value of the stack pointer SP; the peripheral register state information includes at least one of the following: register state information of the pulse width modulation (PWM) module, register state information of the analog-to-digital converter (ADC) module, and register state information of the controller local area network (CAN) module.

[0046] The above implementation method specifically defines the content of the Trap data snapshot. First, it includes the Trap category / subclass number, program counter (PC) value, stack pointer (SP) value, and function call stack data from the program status information. This information can be used to precisely locate where and what type of exception interrupted the software execution flow. Second, it includes peripheral register status information, covering the register contents of key hardware modules such as PWM, ADC, and CAN. This information can be used to record the hardware configuration and actual operating status at the moment of the fault. Combining these two aspects allows analysts to not only know "where the program went wrong" but also "what the hardware was doing at the time of the error." This enables them to differentiate between pure software faults, hardware anomalies, or complex problems caused by software-hardware interactions, greatly improving the accuracy and depth of root cause analysis.

[0047] Based on the aforementioned scheme, in some implementations of this application, the step of generating a Trap data snapshot containing a Trap event identifier and a system state snapshot includes: combining and encapsulating the Trap category number, Trap subclass number, timestamp information, current value of program counter PC, current value of stack pointer SP, function call stack data, and peripheral register state information into a corresponding data packet according to a preset format.

[0048] The above implementation further clarifies the specific composition and generation method of the "Trap data snapshot". Specifically, the snapshot data packet should systematically integrate multi-dimensional information such as fault identifiers, time bases, software execution context, and hardware status. This includes: Trap classification and subclass numbers as event type identifiers; timestamps recording the absolute occurrence time; program counter (PC) and stack pointer (SP) values ​​locking the CPU execution location; function call stack data tracing the execution path; and peripheral register states recording the instantaneous configuration of critical hardware modules. This heterogeneous information is combined and encapsulated into a structured data packet according to a preset format.

[0049] This implementation method achieves standardized and complete encapsulation of fault scene information. By uniformly packaging scattered and multidimensional transient states into a self-contained, well-structured data capsule, it ensures the integrity and consistency of snapshot data during storage, transmission, and subsequent parsing. The preset encapsulation format provides determinism for data serialization and deserialization, enabling cloud-based diagnostic systems to reliably and efficiently reconstruct the precise moment the fault occurred.

[0050] It should be noted that the above implementation method, which combines and encapsulates data into corresponding data packets according to a preset format, refers to the process of sorting, assembling, and packaging various scattered Trap-related data into a single data unit based on a predefined structural template. This predefined structural template specifies the arrangement order, starting position, data length, and encoding method of various data (such as Trap category number and Trap subclass number) in the final data packet. For example, the data combination of the data packet corresponding to a Trap data snapshot can be as follows (208 bytes in total after sequential assembly): Trap category number (1 byte) + Trap Tin number (1 byte) + timestamp (year, month, day, hour, minute, second, 6 bytes) + PC value (4 bytes) + SP value (4 bytes) + 16-level call stack data (64 bytes) + key peripheral register values ​​(PWM, ADC, CAN, etc., 128 bytes).

[0051] Based on the aforementioned scheme, in some implementations of this application, the ring memory includes a real-time recording area and a locked storage area; the step of storing the Trap data snapshot and context key parameters into the ring memory includes: determining whether the hardware Trap trigger event causes the electronic control chip to perform a reset operation; if so, storing the Trap data snapshot and context key parameters into the locked storage area of ​​the ring memory; otherwise, storing the Trap data snapshot and context key parameters into the real-time recording area of ​​the ring memory.

[0052] In the above implementation, the physical space of the ring memory is divided into a real-time recording area and a locked storage area. The storage location of the data is determined according to the severity of the hardware trap event (whether it causes the electronic control chip to reset): serious fault data that causes the system to reset is stored in the locked storage area for permanent storage; ordinary fault data that does not cause a reset is written to the real-time recording area in a loop.

[0053] In this way, not only can the most critical fault evidence that causes the electronic control chip to malfunction be permanently preserved and prevented from being overwritten by subsequent data, but also a large number of general Trap records can be stored in a cyclic overwrite manner, which saves trend data for analyzing occasional and minor faults without exhausting storage space.

[0054] Based on the aforementioned solution, please refer to Figure 2 In some implementations of this application, the step of uploading to the target server includes: Step S201: Performing integrity verification on the Trap data snapshot and context key parameters to obtain the corresponding verification code; Step S202: Encrypting the Trap data snapshot and context key parameters to obtain encrypted data; Step S203: Appending the verification code to the encrypted data to obtain secure transmission data; Step S204: Encapsulating the secure transmission data and transmitting it to the target server through a preset network channel.

[0055] In the above implementation, encryption (e.g., using the AES128 algorithm) ensures that sensitive fault data is not stolen or tampered with during transmission, satisfying vehicle data security and privacy protection requirements. Integrity verification (e.g., using CRC32) is used to detect whether unexpected errors have occurred during data transmission due to channel noise, packet loss, or other reasons. The receiver (cloud server) recalculates the checksum after decryption and compares it with the received value, immediately verifying the data's integrity. The combination of these two methods prevents data leakage or forgery caused by malicious attacks and eliminates data corruption caused by communication interference.

[0056] Based on the aforementioned scheme, in some implementations of this application, the step of uploading to the target server includes: filling the encrypted data packet carrying the Trap data snapshot and context key parameters into the corresponding ODT entry of the preset DAQ list according to the XCP protocol specification, and transmitting it to the target server through a preset network channel.

[0057] In the above implementation, encrypted data packets are organized according to the XCP (General Calibration Protocol) specification. Specifically, the data is filled into the corresponding ODT (Object Descriptor Table) entries in the pre-configured DAQ (Data Acquisition) list, and then transmitted to the target server through a specified network channel (such as Ethernet). Utilizing the XCP protocol, especially Ethernet-based XCP, it can overcome the bandwidth bottleneck of traditional CAN buses, supporting the transmission of full-text Trap data containing the complete context. Furthermore, since the XCP protocol is a widely used standard protocol in the automotive electronics field, the data stream generated by this application can be directly received and parsed by mainstream calibration, measurement, and diagnostic tools on the market, greatly reducing the development complexity and integration cost of cloud-based data receiving and processing systems, making it more practical and feasible.

[0058] It should be noted that XCP (Universal Calibration Protocol) is a standard communication protocol used in the automotive electronics field for ECU calibration, measurement, and flashing. The DAQ list is a task list of which data to be transmitted, and the ODT entries are a detailed packing list for each data packet.

[0059] Exemplary System Please see Figure 3 This application provides a hardware trap data acquisition system for a motor controller, comprising: The Trap monitoring module 101 is configured to: periodically collect key operating parameters of the motor controller and cache them in random access memory; and in response to a hardware Trap trigger event of the electronic control chip, acquire peripheral register status information and program status information of the electronic control chip, generate a Trap data snapshot containing a Trap event identifier and a system status snapshot, and extract the key operating parameters within preset time periods before and after the occurrence of the hardware Trap trigger event from the random access memory to obtain context key parameters; the ring storage module 102 is configured to: store the Trap data snapshot and context key parameters sent by the Trap monitoring module 101; the XCP slave module 103 is configured to: in response to a data upload trigger condition, read the Trap data snapshot and context key parameters from the ring storage module 102 and upload them to the target server.

[0060] For the specific implementation process of the above system, please refer to the motor controller hardware trap data acquisition method provided in the "Exemplary Methods" section, which will not be repeated here.

[0061] Based on the aforementioned scheme, in some implementations of this application, the step of periodically collecting key operating parameters of the motor controller and caching them to random access memory includes: periodically collecting key operating parameters of the motor controller; performing data conversion and structured encapsulation on the collected key operating parameters according to a preset data parsing table to generate data units containing parameter category codes, data type codes, data lengths, and converted values, wherein the data parsing table defines the mapping relationship between parameter category codes, data type codes, data lengths, and data conversion rules for each key operating parameter; and caching the data units to random access memory.

[0062] Based on the aforementioned scheme, in some implementations of this application, the structured encapsulation includes: for each key operating parameter, arranging the parameter category code, data type code, data length, and converted numerical code in sequence to obtain the corresponding encapsulated data; and sequentially concatenating the encapsulated data of multiple key operating parameters to obtain the corresponding data unit.

[0063] Based on the aforementioned scheme, in some implementations of this application, the program state information includes at least one of the following: function call stack data, Trap category number and Trap subclass number corresponding to the hardware Trap trigger event, the current value of the program counter PC, or the current value of the stack pointer SP; the peripheral register state information includes at least one of the following: register state information of the pulse width modulation (PWM) module, register state information of the analog-to-digital converter (ADC) module, and register state information of the controller local area network (CAN) module.

[0064] Based on the aforementioned scheme, in some implementations of this application, the step of generating a Trap data snapshot containing a Trap event identifier and a system state snapshot includes: combining and encapsulating the Trap category number, Trap subclass number, timestamp information, current value of program counter PC, current value of stack pointer SP, function call stack data, and peripheral register state information into a corresponding data packet according to a preset format.

[0065] Based on the aforementioned scheme, in some implementations of this application, the ring memory includes a real-time recording area and a locked storage area; the step of storing the Trap data snapshot and context key parameters into the ring memory includes: determining whether the hardware Trap trigger event causes the electronic control chip to perform a reset operation; if so, storing the Trap data snapshot and context key parameters into the locked storage area of ​​the ring memory; otherwise, storing the Trap data snapshot and context key parameters into the real-time recording area of ​​the ring memory.

[0066] Based on the aforementioned scheme, in some implementations of this application, the step of uploading to the target server includes: performing integrity verification on the Trap data snapshot and context key parameters to obtain the corresponding verification code; encrypting the Trap data snapshot and context key parameters to obtain encrypted data; appending the verification code to the encrypted data to obtain secure transmission data; and encapsulating the secure transmission data and transmitting it to the target server through a preset network channel.

[0067] Based on the aforementioned scheme, in some implementations of this application, the step of uploading to the target server includes: filling the encrypted data packet carrying the Trap data snapshot and context key parameters into the corresponding ODT entry of the preset DAQ list according to the XCP protocol specification, and transmitting it to the target server through a preset network channel.

[0068] To provide a more intuitive understanding of this application for those skilled in the art, a specific example will be used here for illustration. This example integrates the above-mentioned multiple implementation methods to provide a more intuitive explanation of this application. In this example, the system architecture of the motor controller hardware Trap data acquisition system includes a Trap monitoring module 101, a ring storage module 102, and an XCP slave module 103. Specifically: I. System Architecture of Motor Controller Hardware Trap Data Acquisition System (1) The Trap monitoring module 101 includes: Hardware-level triggering mechanism: After detecting the Trap signal, the state of the relevant registers is frozen within 0.5μs.

[0069] Multi-dimensional data capture unit: used to capture the current value of the program counter (PC), the stack pointer (SP) and its associated 16-level call stack data, instantaneous snapshots of key peripheral registers (such as PWM, ADC, CAN, etc.), and key operating parameters of the motor controller (such as current, voltage, speed, temperature, etc.).

[0070] (2) The ring storage module 102 includes: Dual-zone non-volatile memory structure: 1) Real-time recording area: Stores the latest 10 Trap event data in a circular overwrite manner, with each event data being approximately 2KB. 2) Locked storage area: Permanently stores the fatal Trap event data that causes a system restart.

[0071] Dynamic storage strategy: When a fatal Trap event that causes a system restart is detected, its data is written to the locked storage area; for other Trap event data, it is written to the real-time recording area in a loop.

[0072] (3) The XCP slave module 103 includes: Protocol optimization design: 1) Custom DAQ list: Reserve ODT entries 0xF0 to 0xF2 specifically for encapsulating Trap-related data. 2) Event-driven transmission mode: When a Trap event occurs, the corresponding DTO (Data Transfer Object) data packet is automatically activated and uploaded.

[0073] II. Data Processing Flow of Motor Controller Hardware Trap Data Acquisition System (1) Real-time monitoring stage The Trap monitoring module 101 collects 32 key operating parameters of the motor controller, such as U-phase current, bus voltage, motor speed, and module temperature, at a fixed period of 100μs. Data collected in each period is stored as a set in RAM in real time. The system's maximum cache capacity is 100 sets of data, corresponding to a 10ms time window. This design aims to capture instantaneous changes in these parameters.

[0074] (2) Data processing stage For different types of parameters collected, data conversion is required. For example, parameters of type FLOAT32 need to be converted to hexadecimal format for storage, with specific conversion rules referring to the preset data parsing table. To facilitate rapid parsing, each parameter category is assigned a 2-byte unique code and a 1-byte data type code. During storage, the parameter code, data type code, data length, and converted value are stored sequentially. For example, when storing "U-phase current -32.456A", the actual stored 8 bytes of data are "A0 01 01 04 C2 01 D2 F1". After receiving data (such as "A0 03 02 01 2D"), the cloud server also queries the same data parsing table to parse that the data represents "module temperature", with a data type of UINT8, a length of 1 byte, and a value of 45℃. This data parsing table serves as a configuration file and is deployed on both the vehicle-side monitoring system and the cloud server. When it is necessary to add, delete, or modify the collected parameters, only this configuration file needs to be updated. Both the vehicle and cloud sides collect or parse data based on the latest version, which significantly improves the maintainability of the system and reduces maintenance costs.

[0075] (3) Trap triggering and data storage stage 1) Hardware interrupt trigger: When the electronic control chip triggers a hardware trap, it immediately preempts CPU resources through a hardware interrupt and notifies the monitoring system via a callback interface to start the subsequent data storage and reporting process.

[0076] 2) Data Snapshot Generation and Storage: Upon receiving a trigger notification, the Trap monitoring module 101 immediately combines the Trap event information with a snapshot of the system state at the moment of triggering to form a data packet with a fixed format, and stores it in the ring storage module 102. An example of the specific structure of this data packet is as follows: Trap category number (1 byte) + TrapTin number (1 byte) + timestamp (year, month, day, hour, minute, second, total 6 bytes) + PC value (4 bytes) + SP value (4 bytes) + 16-level call stack data (64 bytes) + key peripheral register values ​​(PWM, ADC, CAN, etc., total 128 bytes), totaling 208 bytes.

[0077] 3) Context Parameter Storage: Simultaneously, the Trap monitoring module 101 stores 100 sets (10ms) of key operating parameters already cached in RAM before the trigger moment into the ring storage module 102. After the trigger, it continues to collect and cache the next 100 sets (10ms) of data, also storing them into the ring storage module 102. This completely saves the key operating parameters for 10ms before and after the Trap event (a total of 20ms), providing comprehensive context information for subsequent fault scenario reconstruction and analysis.

[0078] (4) Trap information upload stage XCP slave module 103 integrates the XCP on Eth protocol. After the Trap data is stored in the ring storage module 102, the module sends a signal to the cloud server, notifying it of the occurrence of a Trap event and requesting data upload. For data security, encryption is performed before transmission. The monitoring system and the cloud server share the same AES128 key beforehand; this key, along with the data parsing table, constitutes a security configuration file, which can be updated periodically.

[0079] Upon receiving the notification, the cloud server establishes a connection with the XCP slave module 103 based on the XCP on Eth protocol. After the connection is established, the XCP slave module 103 reads the aforementioned 208-byte Trap data snapshot and key operating parameters from the ring storage module 102 within 20ms before and after the connection. It then encrypts the complete data using a shared AES128 key and sequentially fills the encrypted data into a preset DAQ list (ODT 0xF0~0xF2). Subsequently, based on the XCP on Eth protocol, it uploads the encapsulated data to the cloud server via a 5G network.

[0080] To ensure data integrity and prevent tampering during transmission, the XCP slave module 103 performs a CRC32 calculation on all raw data to be uploaded before encryption, and appends the resulting 4-byte checksum to the end of the encrypted data before sending it. Upon receiving the data, the cloud server first decrypts it using the same key, then recalculates the CRC32 checksum on the decrypted data and compares it with the received checksum. Only when the two match exactly is the data considered valid and processed for reception.

[0081] Exemplary electronic devices Please see Figure 4 This application provides an electronic device including at least one processor 201 and at least one memory 202. The processor 201 and memory 202 are directly connected to each other, or communicate with each other through a communication interface 203, or are electrically connected through one or more communication buses or signal lines to achieve data transmission or interaction. The memory 202 stores program instructions executable by the processor 201, which can call and execute the program instructions to implement a motor controller hardware trap data acquisition method according to various embodiments of this application as described in the "Exemplary Methods" section above. For example, implementing: Key operating parameters of the motor controller are periodically collected and cached in random access memory. In response to a hardware trap trigger event of the electronic control chip, peripheral register status information and program status information of the electronic control chip are obtained, and a trap data snapshot containing a trap event identifier and a system status snapshot is generated. The key operating parameters within a preset time period before and after the occurrence of the hardware trap trigger event are extracted from the random access memory to obtain context key parameters. The trap data snapshot and context key parameters are stored in a ring memory. In response to a data upload trigger condition, the trap data snapshot and context key parameters are read from the ring memory and uploaded to the target server.

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

[0083] The processor 201 can be an integrated circuit chip with signal processing capabilities. The processor 201 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0084] Understandable. Figure 4 The structure shown is for illustrative purposes only; the electronic device may also include components that are more advanced than those shown. Figure 4 The more or fewer components shown, or having the same Figure 4 The different configurations shown. Figure 4 The components shown can be implemented using hardware, software, or a combination thereof.

[0085] Exemplary computer-readable storage media and computer program products This application provides a computer-readable storage medium having a computer program stored thereon. When executed by a processor 201, the computer program implements a motor controller hardware trap data acquisition method according to various embodiments of this application as described in the "Exemplary Methods" section above. For example, it implements: Key operating parameters of the motor controller are periodically collected and cached in random access memory. In response to a hardware trap trigger event of the electronic control chip, peripheral register status information and program status information of the electronic control chip are obtained, and a trap data snapshot containing a trap event identifier and a system status snapshot is generated. The key operating parameters within a preset time period before and after the occurrence of the hardware trap trigger event are extracted from the random access memory to obtain context key parameters. The trap data snapshot and context key parameters are stored in a ring memory. In response to a data upload trigger condition, the trap data snapshot and context key parameters are read from the ring memory and uploaded to the target server.

[0086] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0087] Furthermore, embodiments of this application can also be computer program products, including computer program instructions that, when executed by a processor, implement the steps of a motor controller hardware trap data acquisition method according to various embodiments of this application as described in the "Exemplary Methods" section above. For example, implementing: Key operating parameters of the motor controller are periodically collected and cached in random access memory. In response to a hardware trap trigger event of the electronic control chip, peripheral register status information and program status information of the electronic control chip are obtained, and a trap data snapshot containing a trap event identifier and a system status snapshot is generated. The key operating parameters within a preset time period before and after the occurrence of the hardware trap trigger event are extracted from the random access memory to obtain context key parameters. The trap data snapshot and context key parameters are stored in a ring memory. In response to a data upload trigger condition, the trap data snapshot and context key parameters are read from the ring memory and uploaded to the target server.

[0088] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0089] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, the embodiments should be considered illustrative and non-limiting in all respects, and the scope of this application is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within this application. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A method for acquiring hardware trap data from a motor controller, characterized in that, Includes the following steps: Key operating parameters of the motor controller are periodically collected and cached in random access memory; In response to the hardware Trap trigger event of the electronic control chip, the peripheral register status information and the program status information of the electronic control chip are obtained, a Trap data snapshot containing the Trap event identifier and a system status snapshot is generated, and the key operating parameters within each preset time period before and after the occurrence of the hardware Trap trigger event are extracted from the random access memory to obtain the context key parameters. Store the Trap data snapshot and context key parameters into a ring memory; In response to the data upload trigger condition, the Trap data snapshot and context key parameters are read from the ring memory and uploaded to the target server.

2. The method according to claim 1, characterized in that, The step of periodically acquiring key operating parameters of the motor controller and caching them to random access memory includes: The key operating parameters of the motor controller are periodically collected. According to the preset data parsing table, the collected key operating parameters are converted and structured and encapsulated to generate data units containing parameter category codes, data type codes, data lengths and converted values. The data parsing table defines the mapping relationship between the parameter category codes, data type codes, data lengths and data conversion rules of each key operating parameter. The data unit is cached in random access memory.

3. The method according to claim 2, characterized in that, The structured packaging includes: For each key operating parameter, the parameter category code, data type code, data length, and converted numerical code are arranged in order to obtain the corresponding encapsulated data. The encapsulated data of multiple key operating parameters are sequentially concatenated to obtain the corresponding data units.

4. The method according to claim 1, characterized in that, The program state information includes at least one of the following: function call stack data, Trap category number and Trap subclass number corresponding to the hardware Trap trigger event, and the current value of the program counter PC or the current value of the stack pointer SP. The peripheral register status information includes at least one of the following: register status information of the pulse width modulation (PWM) module, register status information of the analog-to-digital converter (ADC) module, and register status information of the controller area network (CAN) module.

5. The method according to claim 4, characterized in that, The step of generating a Trap data snapshot that includes Trap event identifiers and a system state snapshot includes: The Trap category number, Trap subclass number, timestamp information, current value of program counter PC, current value of stack pointer SP, function call stack data, and peripheral register status information are combined and encapsulated into the corresponding data packet according to a preset format.

6. The method according to claim 1, characterized in that, The ring memory includes a real-time recording area and a locked storage area; The step of storing the Trap data snapshot and context key parameters to the ring memory includes: determining whether the hardware Trap trigger event causes the electronic control chip to perform a reset operation; If so, the Trap data snapshot and context key parameters are stored in the locked storage area of ​​the ring memory; otherwise, the Trap data snapshot and context key parameters are stored in the real-time recording area of ​​the ring memory.

7. The method according to claim 1, characterized in that, The steps of uploading to the target server include: Perform integrity verification on the Trap data snapshot and key context parameters to obtain the corresponding checksum; Encrypt the Trap data snapshot and key context parameters to obtain encrypted data; The verification code is appended to the encrypted data to obtain secure transmission data; After the secure transmission data is encapsulated, it is transmitted to the target server through a preset network channel.

8. The method according to claim 1, characterized in that, The steps of uploading to the target server include: The encrypted data packet, carrying a snapshot of the Trap data and key context parameters, is filled into the corresponding ODT entry of the preset DAQ list according to the XCP protocol specification, and then transmitted to the target server through the preset network channel.

9. A hardware trap data acquisition system for a motor controller, characterized in that, include: The Trap monitoring module is configured to periodically collect key operating parameters of the motor controller and cache them in random access memory. In response to the hardware Trap trigger event of the electronic control chip, the peripheral register status information and the program status information of the electronic control chip are obtained, a Trap data snapshot containing the Trap event identifier and a system status snapshot is generated, and the key operating parameters within each preset time period before and after the occurrence of the hardware Trap trigger event are extracted from the random access memory to obtain the context key parameters. The ring storage module is configured to store snapshots of Trap data and key context parameters sent by the Trap monitoring module. The XCP slave module is configured to: in response to a data upload trigger condition, read the Trap data snapshot and context key parameters from the ring storage module and upload them to the target server.

10. An electronic device, characterized in that, include: Memory, used to store one or more programs; processor; When the one or more programs are executed by the processor, the method as described in any one of claims 1-8 is implemented.

Images