Lightweight uds diagnostic system for automotive electronics

Abstract

The application discloses a lightweight UDS diagnosis system for automobile electronics, and relates to the technical field of automobile electronics.The system is composed of five modules, namely, a shadow construction module, a DMA (Direct Memory Access) transport module, a deviation comparison module, a diagnosis generation module and a benchmark solidification module.After the system is powered on, the shadow construction module divides a special memory area and generates a static mapping table, and the parameter data is automatically transported by a hardware timer triggering DMA; after the DMA transmission is completed, an interrupt is triggered, and the data deviation comparison is completed; in the case of an exception, a diagnosis event is marked through atomic operation; the main loop polls the event flag, calls corresponding diagnosis information and executes a standard UDS diagnosis service; the system writes benchmark values into a storage area in batches when the CPU is idle, and completes state checking and data checking; the application relies on hardware to realize data sampling and transmission, effectively reduces the consumption of main control resources, guarantees the synchronization of sampling data and improves diagnosis reliability.

Description

Technical Field

[0001] This invention relates to the field of automotive electronics technology, specifically a lightweight UDS diagnostic system for automotive electronics. Background Technology

[0002] With the increasing complexity of automotive electronic and electrical architectures, on-board diagnostic systems (UDS) have become a core component for ensuring safe vehicle operation. UDS, as an internationally recognized on-board diagnostic standard, is widely used in modern automotive electronic control units. However, existing lightweight UDS diagnostic systems still have the following shortcomings in the resource-constrained automotive electronic MCU environment: Firstly, diagnostic data sampling largely relies on the CPU to actively execute. Frequent data transfer and comparison operations consume a large amount of CPU resources, affecting the real-time performance of control algorithms and communication tasks. At the same time, the lack of a hardware-automated data synchronization mechanism and the method of sampling each parameter individually result in inconsistent sampling times for each parameter, making it impossible to perform comprehensive diagnosis based on the system state at the same time, which can easily lead to misjudgments. Secondly, existing systems directly execute complex diagnostic logic in interrupt service routines, resulting in excessively long interrupt response times and a lack of atomic operation protection. Third, in the reference value storage stage, most existing technologies adopt the method of writing to Flash in real time. However, frequent erase and write operations not only shorten the lifespan of Flash, but also affect the real-time performance of the system because the write operation is not preemptible. Therefore, there is an urgent need for a lightweight UDS diagnostic system for automotive electronics. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a lightweight UDS diagnostic system for automotive electronics, which solves the problems of high CPU usage, poor real-time performance, and poor reliability in existing lightweight UDS diagnostic systems.

[0004] To achieve the above objectives, the present invention provides the following technical solution: a lightweight UDS diagnostic system for automotive electronics, comprising: The shadow construction module, after the system is powered on and the basic peripherals are initialized, divides the shadow storage area in the fixed address area of ​​memory according to the preset diagnostic monitoring parameter list, allocates an independent shadow unit for each monitoring parameter, and stores the reference base value at the end of the shadow storage area. At the same time, it generates a static mapping table according to the correspondence between the source address of each parameter and the shadow unit. The DMA transfer module is configured with a hardware timer to generate periodic trigger pulses, driving the DMA channel to automatically move the latest values ​​of each parameter source address to the corresponding shadow unit in the order defined by the static mapping table. The deviation comparison module triggers an interrupt service routine after the DMA completes a full transfer. This routine sequentially accesses the new value in the shadow cell and the reference value at the end of the shadow memory area, calculates the absolute deviation between the two, and compares the deviation with the threshold window of the corresponding parameter. If the deviation exceeds the threshold window, the corresponding bit in the diagnostic event flag word is set through atomic operation. Otherwise, the new value is directly overwritten with the reference value, the DMA completion interrupt flag is cleared, and the program exits. In the diagnostic generation module, the UDS diagnostic stack in the main loop continuously polls the diagnostic event flag. Once any bit is detected to be set, it immediately queries the diagnostic event mapping table based on the index value of that bit to obtain the corresponding DTC code and fault snapshot data, and calls the standard UDS diagnostic service to complete the recording of the diagnostic event. When the CPU enters an idle period, the UDS background task first verifies the erase status of the target storage block in the Flash simulated EEPROM area. After the verification is passed, the current reference base value in the shadow storage area is written to the area in batches, and the checksum of the corresponding block is updated after the writing is completed.

[0005] As a further aspect of the present invention, each item in the preset diagnostic monitoring parameter list records metadata for a monitoring variable, which specifically includes the following fields: parameter identifier, parameter source address, shadow offset unit, threshold window number, associated diagnostic information, and enable flag; the associated diagnostic information includes diagnostic fault code, snapshot data storage start address, and snapshot data byte length.

[0006] As a further aspect of the present invention, the specific rules for dividing the shadow storage area in the fixed address region of memory are as follows: Use a preprocessing macro to expand each record in the list of preset diagnostic monitoring parameters and extract its shadow offset unit and data width; During the expansion process, the shadow offset unit of each record is added to the data width to obtain the end offset of the parameter in the shadow storage area. After the macro expansion loop ends, the maximum value of all end offsets is taken as the total byte capacity required by the shadow storage area. Declare a global byte array of length equal to the total capacity, and use the compiler segment attribute to point it to a custom storage segment named SHADOW_RAM, and explicitly define the starting address of the SHADOW_RAM segment as a preset fixed address in the linker script; The compiler and linker work together to place the array at this fixed address, and the contiguous physical space occupied by the array itself constitutes the complete shadow storage area.

[0007] As a further aspect of the present invention, assigning an independent shadow unit to each monitoring parameter is specifically implemented as follows: Based on the total number of parameters and the data width of each parameter in the preset diagnostic monitoring parameter list, calculate the total length of the directory area and the total length of the data area. The total length of the directory area is equal to the total number of parameters multiplied by the fixed number of bytes of each directory entry, and the total length of the data area is equal to the sum of the data widths of all parameters. The first part of the shadow storage area from the fixed base address is designated as the directory index area, and the remaining part is used as the data storage area. When the initialization code block is executed, the entire directory index area is first filled with a zero value, and a temporary value named allocation cursor is set and initialized as the starting address of the data storage area. Read the data width of each monitoring parameter one by one in the order of the list records, and execute the following steps in sequence: write the current value of the allocation cursor into the offset field of the corresponding entry in the directory index area, fill the identifier of this parameter into the identifier field of the same entry, fill the data width into the width field of the same entry, and then add the allocation cursor value to the data width read this time as the starting reference for the next parameter allocation. Once the list has been traversed, each directory entry will record the starting address and size of all shadow units in the data storage area.

[0008] As a further aspect of the present invention, the specific rules for generating the static mapping table are as follows: Each monitoring parameter record is processed item by item according to the order of the preset diagnostic monitoring parameter list; For the i-th parameter, take its real-time data source address constant and fill it into the i-th element of the source address array. At the same time, according to the shadow cell starting offset that has been determined in the shadow storage area for this parameter, fill the offset into the i-th element of the offset array. Both the source address array and the offset array are initialized using constant expressions and placed into the read-only data segment of Flash using linker instructions. This results in two independent arrays of equal length and synchronized order, which together form a static mapping table.

[0009] As a further embodiment of the present invention, the hardware timer includes a low-power timer, a system tick timer, and a general-purpose timer.

[0010] As a further aspect of the present invention, the specific rule for setting the corresponding bit position in the diagnostic event flag word through atomic operations is as follows: When it is determined that the deviation of a certain monitoring parameter exceeds the threshold window, the value 1 is shifted to the left to generate a single-bit mask, using the fixed serial number of the parameter in the preset diagnostic monitoring parameter list as the shift amount. The processor calls the atomic swap instruction to perform a logical OR operation between the mask and the current value of the diagnostic event flag, and writes the result back to the flag storage location. During execution, the atomic swap instruction sends an exclusive access signal to the bus by the processor hardware, preventing any other bus master device or interrupt handler from reading or writing to the memory location during this period.

[0011] As a further aspect of the present invention, the specific operation for constructing the diagnostic event mapping table is as follows: Traverse the list of preset diagnostic monitoring parameters, read the associated diagnostic information for each monitoring parameter record, and concatenate them in a fixed order of "diagnostic fault code → snapshot data storage start address → snapshot data byte length" to form a binary fragment with a total length of nine bytes, which is recorded as a mapping entry. All the mapping entries of the monitoring parameters are concatenated end to end according to the order of the parameters in the list to form a continuous binary data block with a total length equal to the total number of parameters multiplied by nine bytes. This data block is written into a specific segment of Flash in the form of a read-only constant array. The starting address of this segment is fixed by the linker after compilation. The constant array is the diagnostic event mapping table.

[0012] As a further aspect of the present invention, the specific steps for verifying the erase status of the target storage block in the Flash simulated EEPROM area are as follows: The UDS background task determines the base address of the target storage block based on the current rotation index of the Flash simulated EEPROM area; Read a two-byte erase status flag stored at a fixed offset within the target storage block. After the target storage block is erased, the erase completion software actively writes the all-1 value 0xFFFF to this fixed offset to mark that the block is now writable. The background task compares the read flag value with 0xFFFF: if they are equal, the verification passes; otherwise, the verification fails.

[0013] As a further aspect of the present invention, the specific rules for updating the checksum of the corresponding block after writing are as follows: After completing the batch writing of the reference base value to the target storage block, the UDS background task immediately configures the CRC calculation module built into the MCU, and starts a CRC-16 cyclic redundancy check operation with the starting address of the storage block as the input data source and the total number of bytes of the reference base value written this time as the calculation length. After the operation is completed, the obtained 16-bit check code is written into the two-byte check value field at the end of the storage block to overwrite the original content.

[0014] This invention provides a lightweight UDS diagnostic system for automotive electronics, which has the following advantages compared with the prior art: (1) This invention uses a hardware timer to drive DMA to automatically complete the periodic data transfer, avoiding frequent CPU intervention in data transfer. At the same time, it adopts a mechanism of triggering an interrupt after each round of data transfer to ensure the time consistency of all monitoring parameters at the sampling time. (2) This invention uses atomic operations to set the diagnostic event flag, eliminating the flag contention and overwriting problem in a multi-task environment from the hardware level, and moving the complex diagnostic logic to the main loop to avoid the interrupt service routine from taking too long to execute. At the same time, it is combined with the fast indexing mechanism of the static mapping table to improve the response and processing speed of diagnostic events. (3) This invention utilizes the CPU idle time period to batch solidify reference base values, reducing the number of Flash erase and write operations. At the same time, through the erase status verification and CRC verification mechanism, the integrity and correctness of the base value storage are guaranteed. Attached Figure Description

[0015] Figure 1 This is the system principle block diagram of the present invention; Figure 2 This is a flowchart of the process for allocating shadow units for monitoring parameters according to the present invention. Detailed Implementation

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

[0017] like Figure 1 This invention provides a lightweight UDS diagnostic system for automotive electronics; As an embodiment of this application, it includes: The shadow construction module, after the system is powered on and the basic peripherals are initialized, divides the shadow storage area in the fixed address area of ​​memory according to the preset diagnostic monitoring parameter list, allocates an independent shadow unit for each monitoring parameter, and stores the reference base value at the end of the shadow storage area. At the same time, it generates a static mapping table according to the correspondence between the source address of each parameter and the shadow unit. The DMA transfer module is configured with a hardware timer to generate periodic trigger pulses, driving the DMA channel to automatically move the latest values ​​of each parameter source address to the corresponding shadow unit in the order defined by the static mapping table. The deviation comparison module triggers an interrupt service routine after the DMA completes a full transfer. This routine sequentially accesses the new value in the shadow cell and the reference value at the end of the shadow memory area, calculates the absolute deviation between the two, and compares the deviation with the threshold window of the corresponding parameter. If the deviation exceeds the threshold window, the corresponding bit in the diagnostic event flag word is set through atomic operation. Otherwise, the new value is directly overwritten with the reference value, the DMA completion interrupt flag is cleared, and the program exits. In the diagnostic generation module, the UDS diagnostic stack in the main loop continuously polls the diagnostic event flag. Once any bit is detected to be set, it immediately queries the diagnostic event mapping table based on the index value of that bit to obtain the corresponding DTC code and fault snapshot data, and calls the standard UDS diagnostic service to complete the recording of the diagnostic event. When the CPU enters an idle period, the UDS background task first verifies the erase status of the target storage block in the Flash simulated EEPROM area. After the verification is passed, the current reference base value in the shadow storage area is written to the area in batches, and the checksum of the corresponding block is updated after the writing is completed.

[0018] As a second embodiment of this application, it is implemented based on the first embodiment, except that this embodiment includes: The shadow construction module, after the system is powered on and the basic peripherals are initialized, divides the shadow storage area in the fixed address region of memory according to the preset diagnostic monitoring parameter list; During the system power-up phase, it is essential to ensure that the MCU's clock system, interrupt vector table, stack pointer, and memory management unit (if present) are correctly configured. This operation is a prerequisite for the operation of any software. The basic peripheral initialization refers to enabling the pins and clocks of hardware modules directly related to the shadow storage scheme, such as the DMA controller, hardware timer, Flash controller, and CAN bus controller, so that they are in a known ready state. Before peripheral initialization is complete, DMA cannot respond to transfer requests, and timers cannot generate periodic signals, so the establishment of shadow memory lacks hardware support. The preset diagnostic monitoring parameter list is a read-only configuration table stored in non-volatile memory. Each item in the list records the metadata of a monitoring variable, which specifically includes the following fields: parameter identifier, parameter source address, shadow offset unit, threshold window number, associated diagnostic information, and enable flag. Parameter identifier, a unique number or index for each monitored parameter, used to quickly locate the parameter in system interrupts and the UDS stack; The parameter source address is the absolute address of the parameter in the current firmware memory space, and the DMA periodically fetches real-time data from this address. The shadow offset unit is the offset of a pre-allocated unit in the shadow storage area for this parameter, and the DMA target address is determined from this. The threshold window number points to a set of upper and lower limit offsets, defining the allowable fluctuation range of this parameter; Associated diagnostic information, including diagnostic fault codes, snapshot data storage start address, and snapshot data byte length: Diagnostic fault codes are three bytes long. These codes follow the encoding rules of DTCs in the UDS standard and represent the fault path, fault category, and specific fault cause. They are the unique identifiers for diagnostic instruments to identify faults. The snapshot data storage start address is four bytes long. This address is the starting position of a continuous space reserved in the ECU memory for storing the fault snapshot of this parameter. It records the first address of the relevant environmental data (such as voltage, temperature, timestamp, etc.) that need to be frozen when the fault occurs. The snapshot data length is two bytes, indicating the total number of bytes occupied by the faulty snapshot data in memory; Enable flag: Whether to monitor this parameter to support dynamic masking at different operational stages (such as development, production, and after-sales). The specific rules for dividing the shadow storage area in the fixed address region of memory are as follows: The preprocessing macro expands each record in the preset diagnostic monitoring parameter list item by item, extracting its shadow offset unit (provided directly by the list) and data width (which can be obtained by querying the UDS standard data length table based on the parameter identifier in the list). During the expansion process, the shadow offset unit of each record is added to the data width to obtain the end offset of the parameter in the shadow storage area. After the macro expansion loop ends, the maximum value of all end offsets is taken as the total byte capacity required by the shadow storage area. The code declares a global byte array with a length equal to the total capacity, and uses the compiler segment attribute to point it to a custom storage segment named SHADOW_RAM. The linker script explicitly defines the starting address of the SHADOW_RAM segment as a preset fixed address. The compiler and linker work together to place the array at this fixed address, and the contiguous physical space occupied by the array itself constitutes the complete shadow storage area; Each monitoring parameter is assigned an independent shadow unit, and reference baseline values ​​are stored centrally at the end of the shadow storage area; A static mapping table is generated based on the correspondence between the source address and shadow unit of each parameter. The specific rules are as follows: Each monitoring parameter record is processed item by item according to the order of the preset diagnostic monitoring parameter list; For the i-th parameter, take its real-time data source address constant and fill it into the i-th element of the source address array. At the same time, according to the shadow cell starting offset that has been determined in the shadow storage area for this parameter, fill the offset into the i-th element of the offset array. Both arrays are initialized using constant expressions and placed into the read-only data segment of Flash memory via linker instructions, ultimately generating two independent arrays of equal length and synchronized order, which together constitute the static mapping table.

[0019] In a resource-constrained MCU, the CPU not only needs to run the diagnostic stack, but also handle multiple real-time tasks such as CAN communication, sensor data processing, and control algorithms. If the CPU needs to actively initiate DMA configuration or execute software delays for each sampling, it will frequently interrupt the currently executing tasks, resulting in a decrease in the overall system throughput. After configuring the hardware timer to generate periodic trigger pulses, the timer's PWM output or update event can be directly connected to the channel request input of the DMA controller, forming a pure hardware trigger link. After the CPU initially configures the timer cycle and DMA channel parameters, it completely detaches itself from the sampling loop. All subsequent sampling actions are completed autonomously by the hardware. The CPU only intervenes in the comparison process when it is notified by an interrupt that a round of data transfer has ended, thus achieving a complete separation of sampling and calculation. The hardware timers include low-power timers, system tick timers, and general-purpose timers; Taking a low-power timer as an example, it is a timing peripheral that can be driven by an independent low-speed clock when the main power domain of the chip is turned off or the main clock stops. In this system, when the ECU enters sleep mode (such as the silent state after the vehicle is turned off), the CPU core clock and high-speed peripheral clock are both turned off. However, the low-power timer can continuously count and generate periodic output events by keeping the low-speed clock enabled and the frequency divider configured. This output event is directly connected to the channel request end of the DMA controller, triggering the DMA to briefly wake up from sleep mode. After completing a transfer from the source address to the shadow unit, it immediately returns to sleep mode. In this way, the ECU can continuously refresh diagnostic data at intervals of seconds or minutes with an average power consumption of less than 100 microamps, realizing the UDS diagnostic capability of not going offline when the engine is off. In terms of configuration, only the division value of the low-power timer, the value of the auto-reload register, and the output trigger selection bit need to be set, without occupying any CPU interrupt resources, which is in line with the lightweight design principle of resource-constrained MCUs. The DMA channel automatically moves the latest values ​​of each parameter source address to the corresponding shadow unit according to the order defined in the static mapping table. The CPU does not participate in the data movement during the entire process. In traditional DMA-free designs, sampling each parameter requires the CPU to execute multiple load and store instructions to read real-time data byte by byte from the source address into the register and then write it to the target address. When the number of monitored parameters is large and the data width varies, the number of instructions used by the CPU to move data increases proportionally with the number of parameters, directly affecting the response latency of the diagnostic stack and the overall system performance. In addition, the real-time values ​​of multiple monitoring parameters are often stored in the MCU memory space in a scattered manner. If the CPU recalculates the source address and target address of the next parameter before each DMA transfer, it will not only waste computing power, but also easily lead to address out-of-bounds or overwriting due to code vulnerabilities. After the source address and corresponding shadow unit offset of each parameter are fixed in the static mapping table according to the preset list order, the DMA channel only needs to read the configuration items sequentially starting from the first address of the table. Each configuration item clearly indicates the source and destination of this transfer, making the entire transfer sequence clearer and more specific.

[0020] In the deviation comparison module, there is often a physical relationship between the monitored parameters (such as current and voltage in the same control loop), and the diagnostic system needs to judge the system status based on the set of sampled values ​​at the same time; otherwise, it may produce incorrect deviation conclusions. If an interrupt is triggered immediately after each parameter is transferred, when the interrupt for the first parameter is completed but the transfer of subsequent parameters has not yet been completed, the sampled values ​​in each shadow unit will actually come from different sampling times. By having the DMA generate an interrupt after a complete round of data transfer, it is ensured that all parameters covered by that round of data transfer are updated based on the same timer trigger cycle, making the sample set stored in the shadow storage area highly consistent in time. The system sequentially accesses the new value in the shadow cell (which is the latest sampled data that the DMA has just moved from the parameter source address to the shadow cell) and the reference value located at the end of the shadow memory area. It calculates the absolute deviation between the two for each item and compares the deviation with the threshold window of the corresponding parameter (which can be obtained from the threshold window number in the preset diagnostic monitoring parameter list). If the deviation exceeds the threshold window, the corresponding bit in the diagnostic event flag word is set through atomic operation. Otherwise, the reference value is directly overwritten with the new value. Then, the DMA completion interrupt flag is cleared and the system exits. The diagnostic event flag refers to a bitmap variable stored in the MCU memory, where each bit corresponds to a specific monitoring parameter in a preset list of diagnostic monitoring parameters; The specific rules for setting the corresponding bits in the diagnostic event flag word through atomic operations are as follows: When it is determined that the deviation of a certain monitoring parameter exceeds the threshold window, the value 1 is shifted to the left to generate a single-bit mask, using the fixed serial number of the parameter in the preset diagnostic monitoring parameter list as the shift amount. Then, the atomic swap instruction provided by the processor is invoked to perform a logical OR operation between the mask and the current value of the diagnostic event flag, and the result is written directly back to the flag storage location. During execution, the atomic swap instruction sends an exclusive access signal to the bus by the processor hardware, preventing any other bus master device or interrupt handler from reading or writing to the memory location during this period, thereby completing the atomic setting of the target bit, while the state of the remaining bits remains unaffected.

[0021] In the diagnostic generation module, the UDS diagnostic stack in the main loop continuously polls the diagnostic event flag word. Each time the loop body is fully executed, an event collection action is performed: first, a load instruction is used to fully read the current value of the diagnostic event flag word into the local variable, and then a clear instruction is used to set all the original flag word storage locations to zero; if the local variable is a non-zero value, then each bit of the local variable is traversed from the low bit to the high bit, and each bit is compared to see if it is set. Once any bit is set, the diagnostic event mapping table is queried immediately according to the index value of that bit to obtain the corresponding DTC code and fault snapshot data, and the standard UDS diagnostic service is called to complete the recording of the diagnostic event. The specific steps for constructing the diagnostic event mapping table are as follows: Traverse the list of preset diagnostic monitoring parameters, read the associated diagnostic information for each monitoring parameter record, and concatenate them in a fixed order of "diagnostic fault code → snapshot data storage start address → snapshot data byte length" to form a binary fragment with a total length of nine bytes, which is recorded as a mapping entry. All the mapping entries of the monitoring parameters are concatenated end to end according to the order of the parameters in the list to form a continuous binary data block with a total length equal to the total number of parameters multiplied by nine bytes. This data block is written into a specific segment of Flash in the form of a read-only constant array. The starting address of this segment is fixed by the linker after compilation. The constant array is the diagnostic event mapping table.

[0022] In the baseline hardening module, when the CPU enters an idle period, the UDS background task first verifies the erase status of the target storage block in the Flash simulated EEPROM area. The specific operation is as follows: The UDS background task determines the base address of the target storage block based on the current rotation index of the Flash simulated EEPROM area; Read a two-byte erase status flag stored at a preset fixed offset within the block. After the target storage block is erased, the erase completion software actively writes the all-1 value 0xFFFF to this fixed offset to mark that the block is now writable. The background task compares the read flag value with 0xFFFF: if they are equal, the verification passes, indicating that the target storage block is in an erased and writable state; otherwise, the verification fails, indicating that the block still contains historical data and the erasure operation needs to be triggered first. After successful verification, the current reference values ​​in the shadow storage area are written to this area in batches, and the checksum of the corresponding block is updated after the writing is completed. The specific rules are as follows: After completing the batch writing of the reference base value to the target storage block, the UDS background task immediately configures the CRC calculation module built into the MCU, and starts a CRC-16 cyclic redundancy check operation with the starting address of the storage block as the input data source and the total number of bytes of the reference base value written this time as the calculation length. After the operation is completed, the obtained 16-bit check code is written into the two-byte check value field at the end of the storage block to overwrite the original content.

[0023] As a third embodiment of this application, this embodiment further discloses a method for allocating shadow units for monitoring parameters based on embodiments one and two, such as... Figure 2 As shown, the specific content includes: Based on the total number of parameters and the data width of each parameter in the preset diagnostic monitoring parameter list, calculate the total length of the directory area and the total length of the data area. The total length of the directory area is equal to the total number of parameters multiplied by the fixed number of bytes of each directory entry, and the total length of the data area is equal to the sum of the data widths of all parameters. The first part of the shadow storage area from the fixed base address is designated as the directory index area, and the remaining part is used as the data storage area. When the initialization code block is executed, the entire directory index area is first filled with a zero value, and a temporary value named allocation cursor is set and initialized as the starting address of the data storage area. Read the data width of each monitoring parameter one by one in the order of the list records, and execute the following steps in sequence: write the current value of the allocation cursor into the offset field of the corresponding entry in the directory index area, fill the identifier of this parameter into the identifier field of the same entry, fill the data width into the width field of the same entry, and then add the allocation cursor value to the data width read this time as the starting reference for the next parameter allocation. Once the list has been traversed, each directory entry will record the starting address and size of all shadow units in the data storage area.

[0024] Some of the data in the above formulas are numerical calculations with dimensions removed, and the contents not described in detail in this specification are all prior art known to those skilled in the art.

[0025] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. A lightweight UDS diagnostic system for automotive electronics, characterized in that, include: The shadow construction module, after the system is powered on and the basic peripherals are initialized, divides the shadow storage area in the fixed address area of ​​memory according to the preset diagnostic monitoring parameter list, allocates an independent shadow unit for each monitoring parameter, and stores the reference base value at the end of the shadow storage area. At the same time, it generates a static mapping table according to the correspondence between the source address of each parameter and the shadow unit. The DMA transfer module is configured with a hardware timer to generate periodic trigger pulses, driving the DMA channel to automatically move the latest values ​​of each parameter source address to the corresponding shadow unit in the order defined by the static mapping table. The deviation comparison module triggers an interrupt service routine after the DMA completes a full transfer. This routine sequentially accesses the new value in the shadow cell and the reference value at the end of the shadow memory area, calculates the absolute deviation between the two, and compares the deviation with the threshold window of the corresponding parameter. If the deviation exceeds the threshold window, the corresponding bit in the diagnostic event flag word is set through atomic operation. Otherwise, the new value is directly overwritten with the reference value, the DMA completion interrupt flag is cleared, and the program exits. In the diagnostic generation module, the UDS diagnostic stack in the main loop continuously polls the diagnostic event flag. Once any bit is detected to be set, it immediately queries the diagnostic event mapping table based on the index value of that bit to obtain the corresponding DTC code and fault snapshot data, and calls the standard UDS diagnostic service to complete the recording of the diagnostic event. When the CPU enters an idle period, the UDS background task first verifies the erase status of the target storage block in the Flash simulated EEPROM area. After the verification is passed, the current reference base value in the shadow storage area is written to the area in batches, and the checksum of the corresponding block is updated after the writing is completed.

2. The lightweight UDS diagnostic system for automotive electronics according to claim 1, characterized in that, Each item in the preset diagnostic monitoring parameter list records metadata for a monitoring variable, which specifically includes the following fields: parameter identifier, parameter source address, shadow offset unit, threshold window number, associated diagnostic information, and enable flag; the associated diagnostic information includes diagnostic fault code, snapshot data storage start address, and snapshot data byte length.

3. The lightweight UDS diagnostic system for automotive electronics according to claim 1, characterized in that, The specific rules for allocating a shadow storage area within a fixed memory address region are as follows: Use a preprocessing macro to expand each record in the list of preset diagnostic monitoring parameters and extract its shadow offset unit and data width; During the expansion process, the shadow offset unit of each record is added to the data width to obtain the end offset of the parameter in the shadow storage area. After the macro expansion loop ends, the maximum value of all end offsets is taken as the total byte capacity required by the shadow storage area. Declare a global byte array of length equal to the total capacity, and use the compiler segment attribute to point it to a custom storage segment named SHADOW_RAM, and explicitly define the starting address of the SHADOW_RAM segment as a preset fixed address in the linker script; The compiler and linker work together to place the array at this fixed address, and the contiguous physical space occupied by the array itself constitutes the complete shadow storage area.

4. The lightweight UDS diagnostic system for automotive electronics according to claim 1, characterized in that, The specific operation of assigning an independent shadow unit to each monitoring parameter is as follows: Based on the total number of parameters and the data width of each parameter in the preset diagnostic monitoring parameter list, calculate the total length of the directory area and the total length of the data area. The total length of the directory area is equal to the total number of parameters multiplied by the fixed number of bytes of each directory entry, and the total length of the data area is equal to the sum of the data widths of all parameters. The first part of the shadow storage area from the fixed base address is designated as the directory index area, and the remaining part is used as the data storage area. When the initialization code block is executed, the entire directory index area is first filled with a zero value, and a temporary value named allocation cursor is set and initialized as the starting address of the data storage area. Read the data width of each monitoring parameter one by one in the order of the list records, and execute the following steps in sequence: write the current value of the allocation cursor into the offset field of the corresponding entry in the directory index area, fill the identifier of this parameter into the identifier field of the same entry, fill the data width into the width field of the same entry, and then add the allocation cursor value to the data width read this time as the starting reference for the next parameter allocation. Once the list has been traversed, each directory entry will record the starting address and size of all shadow units in the data storage area.

5. A lightweight UDS diagnostic system for automotive electronics according to claim 1, characterized in that, The specific rules for generating static mapping tables are as follows: Each monitoring parameter record is processed item by item according to the order of the preset diagnostic monitoring parameter list; For the i-th parameter, take its real-time data source address constant and fill it into the i-th element of the source address array. At the same time, according to the shadow cell starting offset that has been determined in the shadow storage area for this parameter, fill the offset into the i-th element of the offset array. Both the source address array and the offset array are initialized using constant expressions and placed into the read-only data segment of Flash using linker instructions. This results in two independent arrays of equal length and synchronized order, which together form a static mapping table.

6. A lightweight UDS diagnostic system for automotive electronics according to claim 1, characterized in that, The hardware timers include low-power timers, system tick timers, and general-purpose timers.

7. A lightweight UDS diagnostic system for automotive electronics according to claim 1, characterized in that, The specific rules for setting the corresponding bits in the diagnostic event flag word through atomic operations are as follows: When it is determined that the deviation of a certain monitoring parameter exceeds the threshold window, the value 1 is shifted to the left to generate a single-bit mask, using the fixed serial number of the parameter in the preset diagnostic monitoring parameter list as the shift amount. The processor calls the atomic swap instruction to perform a logical OR operation between the mask and the current value of the diagnostic event flag, and writes the result back to the flag storage location. During execution, the atomic swap instruction sends an exclusive access signal to the bus by the processor hardware, preventing any other bus master device or interrupt handler from reading or writing to the memory location during this period.

8. A lightweight UDS diagnostic system for automotive electronics according to claim 1, characterized in that, The specific steps for constructing the diagnostic event mapping table are as follows: Traverse the list of preset diagnostic monitoring parameters, read the associated diagnostic information for each monitoring parameter record, and concatenate them in a fixed order of "diagnostic fault code → snapshot data storage start address → snapshot data byte length" to form a binary fragment with a total length of nine bytes, which is recorded as a mapping entry. All the mapping entries of the monitoring parameters are concatenated end to end according to the order of the parameters in the list to form a continuous binary data block with a total length equal to the total number of parameters multiplied by nine bytes. This data block is written into a specific segment of Flash in the form of a read-only constant array. The starting address of this segment is fixed by the linker after compilation. The constant array is the diagnostic event mapping table.

9. A lightweight UDS diagnostic system for automotive electronics according to claim 1, characterized in that, The specific steps for verifying the erase status of the target storage block in the Flash simulated EEPROM area are as follows: The UDS background task determines the base address of the target storage block based on the current rotation index of the Flash simulated EEPROM area; Read a two-byte erase status flag stored at a fixed offset within the target storage block. After the target storage block is erased, the erase completion software actively writes the all-1 value 0xFFFF to this fixed offset to mark that the block is now writable. The background task compares the read flag value with 0xFFFF: if they are equal, the verification passes; otherwise, the verification fails.

10. A lightweight UDS diagnostic system for automotive electronics according to claim 1, characterized in that, After the write operation is complete, the checksum of the corresponding block is updated according to the following rules: After completing the batch writing of the reference base value to the target storage block, the UDS background task immediately configures the CRC calculation module built into the MCU, and starts a CRC-16 cyclic redundancy check operation with the starting address of the storage block as the input data source and the total number of bytes of the reference base value written this time as the calculation length. After the operation is completed, the obtained 16-bit check code is written into the two-byte check value field at the end of the storage block to overwrite the original content.

Images