MCU online upgrade method based on CAN bus UDS diagnostic service

Abstract

The present invention relates to the field of vehicle engineering technology, and more specifically to an MCU online upgrade method based on a CAN bus UDS diagnostic service. The method first divides the MCU memory areas for the boot and app programs, then completes the MCU program jump from boot to app, and resets the MCU from app to boot. Then, based on the UDS diagnostic service, the method uses a Zhou Ligong host computer to complete the online upgrade. During the jump verification of the program jump between the bootloader and the app, the method also verifies the validity of the app program through a CRC cyclic redundancy check. Experimental verification has shown that the method can effectively complete the app program update based on the UDS service, and encapsulate ADAS assisted driving related algorithms into the app for burning.

Description

Technical Field

[0001] The present invention relates to the field of vehicle engineering technology, and in particular to an MCU online upgrade method based on a CAN bus UDS diagnostic service. Background Art

[0002] With the advancement of intelligent, connected, and electrified vehicles, the volume and complexity of automotive software are increasing, requiring frequent updates and maintenance. Over-the-Air (OTA) upgrades—remote upgrades and updates via wireless networks—are crucial for both automakers and car owners. OTA technology allows automakers to remotely upgrade and update vehicle software and systems without requiring owners to return their vehicles to a repair shop. This significantly reduces repair shop workload and costs, allowing for faster rollout of new software features and improvements, improving vehicle competitiveness and user experience. Summary of the Invention

[0003] The purpose of the present invention is to provide an MCU online upgrade method based on the CAN bus UDS diagnostic service, complete the update of the App program based on the UDS service, encapsulate the relevant algorithm into the App for burning, and complete the online upgrade operation.

[0004] To achieve the above object, the present invention provides an MCU online upgrade method based on a CAN bus UDS diagnostic service, comprising the following steps:

[0005] Step 1: Select CAN bus driver;

[0006] Step 2: Divide the storage area for Bootloader and App link files;

[0007] Step 3: Complete the MCU program jump from boot to App;

[0008] Step 4: Use the hardware watchdog to reset the MCU so that the App jumps to Boot.

[0009] Step 5: Implement OTA online upgrade of the program through UDS diagnostic service.

[0010] Optionally, in step 2, both the Bootloader and the App program divide the storage area in the Flash and SDRAM, and the App CRC value stored in the swap area in the Bootloader program is compared with the App CRC value calculated by the boot.

[0011] Optionally, the execution process of step 3 includes the following steps:

[0012] Step 3.1: Redirect the interrupt vector table and set the address of the interrupt vector table to the starting address of the App program;

[0013] Step 3.2: Redirect the main stack pointer to the address stored in the start address of the App program;

[0014] Step 3.3: Redirect the address pointed to by the program counter pointer;

[0015] Step 3.4: Complete the address of the corresponding App program through the function pointer.

[0016] Optionally, in step 4, when the App jumps to the Boot program, the watchdog timeout is set to 0 to reset the MCU.

[0017] Optionally, the program jump verification between the Bootloader and the App is implemented through CRC verification. Before the Boot program jumps to the App program, a CRC check is required. The Boot program generates a corresponding CRC-16 polynomial value and compares it with the CRC value stored in the App. If the CRC values ​​are equal, the data is complete and the App is valid, and the corresponding program jump is performed; before the App jumps to the Boot to reset the MCU, the CRC value generated by the App is compared with the CRC check value stored in the swap area in the Boot. If the CRC values ​​are equal, the data is complete and the Boot is valid, and the MCU reset operation is performed.

[0018] Optionally, in step 5, use Zhou Ligong's host computer to flash the script, transmit messages through the service ID of the UDS protocol, load the updated App program online through the UDS service, and finally complete the MCU reset.

[0019] This invention provides an MCU online upgrade method based on the CAN bus UDS diagnostic service. The method first partitions the MCU memory areas for the boot and app programs, then performs an MCU program jump from boot to app and an MCU reset from app to boot. Finally, the method uses the UDS diagnostic service to complete the online upgrade using a host computer. During the jump verification of the program jump between the bootloader and app, the method also verifies the validity of the app program through a CRC cyclic redundancy check. Experimental verification has demonstrated that the method can effectively complete app program updates based on the UDS service and encapsulate ADAS-related assisted driving algorithms into the app for burning. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0021] Figure 1 The present invention is a schematic diagram of a specific implementation flow of an MCU online upgrade method based on a CAN bus UDS diagnostic service.

[0022] Figure 2 This is a diagram of the standard format of the CAN data frame.

[0023] Figure 3 Schematic diagram of the CAN bus hardware design in an embodiment of the present invention.

[0024] Figure 4 It is a schematic diagram of the Bootloader storage area division of the present invention.

[0025] Figure 5 This is a schematic diagram of the App storage area division of the present invention.

[0026] Figure 6 It is a schematic diagram of the MCU startup process of the present invention.

[0027] Figure 7 This is a schematic diagram of the hardware structure of an independent watchdog.

[0028] Figure 8 This is a schematic diagram of the time parameter composition of multi-frame transmission between the ECU transmitting end and the receiving end in an embodiment of the present invention.

[0029] Figure 9 This is a flowchart of the OTA upgrade process based on the UDS service.

[0030] Figure 10 This is a diagram of the implementation interface of the Zhou Ligong tool used in the embodiment of the present invention. DETAILED DESCRIPTION

[0031] The following describes embodiments of the present invention in detail, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present invention, and are not to be construed as limiting the present invention.

[0032] The following is a description of some of the English abbreviations used in this invention:

[0033] OTA: Over-The-Air, online upgrade;

[0034] CAN: Controller Area Network, bus;

[0035] UDS: Unified Diagnostic Services, unified diagnostic services;

[0036] CRC: Cyclic Redundancy Check, cyclic redundancy check;

[0037] MCU: Micro Controller Unit, micro control unit;

[0038] ECU: Electronic Control Unit, electronic control unit.

[0039] See also Figure 1 The present invention provides an MCU online upgrade method based on the CAN bus UDS diagnostic service, comprising the following steps:

[0040] S1: Select CAN bus driver;

[0041] S2: Divide the storage area for Bootloader and App link files;

[0042] S3: Complete the MCU program jump from boot to App;

[0043] S4: Use the hardware watchdog to reset the MCU so that the App jumps to the Boot state.

[0044] S5: Implement OTA online upgrade of the program through UDS diagnostic service.

[0045] The present invention will be further described below in conjunction with corresponding terms:

[0046] 1. CAN bus

[0047] CAN (Controller Area Network) bus is a serial communication protocol used for data communication between multiple nodes, and is widely used in automotive electronics, industrial automation and other fields. CAN bus is a serial communication bus based on a multi-master architecture, which allows multiple nodes in the network to initiate communication requests at any time. It is suitable for environments with strong real-time performance and a large number of nodes. Its basic features include: Multi-master architecture: All nodes can send and receive data, allowing multiple controllers to communicate on the same bus. Data priority and arbitration mechanism: The message priority is determined by the message ID (identifier) ​​to ensure that important data is transmitted first. High reliability: CAN has powerful error detection and processing capabilities to ensure data integrity and reliability. The standard frame format of CAN data frame is as follows: Figure 2 As shown: It includes arbitration segment (message ID), control segment (message length DLC), data segment, CRC segment (to ensure data integrity and detect errors during transmission), and ACK segment (to confirm successful reception and ensure the reliability of data transmission).

[0048] The CAN bus uses two signal lines, CAN_H and CAN_L, for data transmission. The common connection method is differential transmission. Its logic level is defined as follows: Dominant: CAN_H is more than 0.9V higher than CAN_L, and the corresponding logic value is 0; Recessive: The voltage difference between CAN_H and CAN_L is small (about 0.2V or less), and the corresponding logic value is 1. The CAN protocol contains a variety of error detection mechanisms to ensure the reliability of data transmission. These mechanisms include: Bit stuffing error: inserting the opposite bit after 5 consecutive identical bits to prevent the receiver from being unable to synchronize; Frame format error: when the structure or format of the frame does not conform to the protocol definition, an error is triggered;

[0049] A parity error occurs when the receiver checks the data against the CRC field; a mismatch triggers an error. An acknowledgement error occurs when the receiver fails to send an ACK, indicating that the data was not received correctly. A bit monitoring error occurs when the voltage levels of the transmitter and receiver are out of sync. When these errors accumulate to a certain level, the faulty node enters the Bus-Off state and exits the network to prevent it from disrupting the normal communication of other nodes. The CAN bus, with its multi-master architecture, priority-based arbitration mechanism, and efficient error detection, has become a highly reliable communication protocol for embedded systems. Figure 3 The CAN bus hardware design is the CAN bus hardware design for NXPS32K144, which converts digital signals into CAN_H and CAN_L differential signals through the TJA1050 transceiver.

[0050] 2. Memory flash partition design.

[0051] MCU program jump involves the division of memory addresses in Flash and SDRAM, as well as the division of storage areas for the CRC checksum values ​​and jump valid flag values ​​for jumps from Boot to App and App to Boot. Figure 4 That is, the storage area division between Flash and SDRAM in the Bootloader program, where the swap area stores the App's CRC value and compares it with the AppCRC value calculated by the boot. Figure 5 That is, the division of storage areas in the App program.

[0052] 3. CAN program jump principle

[0053] The MCU power-on program startup process: 1) Initialize the stack pointer (SP) and program counter (PC), initialize the data segment and bss segment; 2) Set the stack pointer to point to the top address of the memory, initialize global variables: copy the initialized global variables to RAM; clear the bss segment: clear the uninitialized global variable segment (bss segment); initialize the clock: set the main clock and PLL to the operating frequency; 3) Disable the watchdog timer, configure the GPIO pin direction (input / output); set the access control of the external RAM / Flash controller; 4) Initialize system-level functional modules, including the interrupt controller, clock divider and power management module; 5) Configure the interrupt vector table address to make the system interrupt and exception handling mechanism ready; 6) After completing all initialization tasks, the startup code will jump to the main function main(). Figure 6 Illustration of the MCU startup process, which shows the jump process of the STM32 main stack pointer (SP) and program counter (PC) during the MCU startup process.

[0054] Furthermore, the software code design for CAN jumping from the Boot program to the App program can be designed by referring to the MCU power-on program startup process. 1) Redirect the interrupt vector table: Set the interrupt vector table address to the App program's starting address; 2) Redirect the main stack pointer (SP) to point to the address stored in the App program's starting address (implemented by dereferencing); 3) Redirect the address pointed to by the program counter (PC) pointer (dereference the address corresponding to the App program's starting address + 4); 4) Complete the corresponding App program address through the function pointer (the function pointer points to the address corresponding to the PC program counter); Through the above steps, the corresponding program jump operation can be completed. CAN program jump is a routine based on the STM32 Boot program jumping to the App program.

[0055] 4. Hardware Watchdog

[0056] The watchdog is a hardware MCU reset solution based on the timer. Figure 7The figure below shows the hardware register design for an independent watchdog. This independent watchdog adds a periodic reload value to a downcounter, commonly known as feeding the watchdog. If the watchdog fails to periodically feed the watchdog, the downcounter continues to decrement to zero, resetting the MCU. This watchdog design allows the app to jump to the boot program, resetting the MCU, and resetting the MCU when a hardware error occurs.

[0057] In the present invention, the App jumps to the Boot program, that is, the MCU is reset by setting the timeout period of the watchdog to 0.

[0058] 5. UDS

[0059] Unified Diagnostic Services (UDS) is a CAN bus-based communication protocol primarily used for inter-automotive electronic control unit (ECU) diagnostics and online / unconscious ECU upgrades. The UDS protocol is an intelligent ECU solution based on the ISO14229 and ISO15765 standards for automotive electronic fault diagnosis and online / unconscious control software upgrades. ISO14229 includes a series of service IDs (SIDs): Diagnostic Session Control (0x10), ECU Reset (0x11), Security Access (0x27), Read DID Data (0x22), Write DID Data (0x2E), Clear DTC (0x14), Read DTC Information (0x19), Request Download (0x34), Transfer Data (0x36), and Request Data Transfer Exit (0x37). An ECU reset is equivalent to an MCU reset. In the UDS protocol, DIDs are used to identify and access specific stored data, such as sensor status, configuration information, or fault codes, during diagnostic communications. A DTC is a unique identifier representing a specific fault or anomaly within an automotive electronic control unit (ECU). Request to download, the transmission data is transmitted through the MCU's Flash write, erase, read and other functions. ISO15765 divides CAN messages into single frame (SF), first frame (FF), continuous frame (CF), and flow control frame (FC). The first frame (FF) is the first frame of multi-frame transmission. The flow control frame (FC) specifies the carrying capacity of multi-frame transmission of CAN messages. The flow control frame message includes two parameters, BS and STmin. BS indicates the maximum number of consecutive N_PDU frames that the receiver allows the sender to send continuously. BS indicates the maximum number of consecutive frames that the sender can send. The design purpose of the ISO15765 protocol is mainly to solve the limited amount of data carried by single-frame CAN messages and meet the needs of multi-byte data transmission. When sending diagnostic messages, data larger than 8 bytes are sent in segments. When receiving diagnostic messages, data larger than 8 bytes are reassembled. The multi-frame transmission of CAN involves a series of network time parameters in the ISO15765 standard. Figure 8 The network layer time parameters specify the time parameters for multi-frame transmission between the ECU sender and receiver.

[0060] N_As: the time it takes for the transmitter to send a CAN frame; N_Ar: the time it takes for the receiver to send a CAN frame; N_Bs: the time it takes for the transmitter to finish sending the first frame or the continuation frame; N_Br: the time it takes for the receiver to receive the first frame or the flow control frame; N_Cs: the time it takes for the transmitter to receive the flow control frame or the continuation frame and request to send the next continuous frame; N_Cr: the time it takes for the receiver to finish sending the flow control frame or receive the continuation frame and receive the next continuous frame.

[0061] Furthermore, CRC cyclic redundancy check is an error detection method used to verify the integrity of data during transmission or storage. It uses polynomial operations to detect possible errors in data. The core principle of CRC is to generate a check value through polynomial division and append it to the end of the data. The receiving end also performs the same calculation and compares the check value to determine whether the data has errors. CRC check can effectively detect common errors in transmission, such as: single-bit error: if only one bit is wrong, CRC will inevitably detect an error; double-bit error: when the length of the generated polynomial is N bits, it can detect double-bit errors with a separation distance less than N. The CRC check of the data transmission program jump between the App and Boot of the present invention usually adopts CRC-16, and the polynomial expression of CRC-16 is: x16+x12+x5+1.

[0062] The CRC-16 polynomial is widely used in communication protocols and embedded systems to detect the integrity of larger data blocks, such as code storage verification. It is suitable for program jump verification between the Bootloader and the App. Before the Boot program jumps to the App program, a CRC check is required. The Boot program generates a corresponding CRC-16 polynomial value and compares it with the CRC value stored in the App. If the CRC values ​​are equal, the data is complete and the App is valid, and the corresponding program jump is performed. Before the App jumps to the Boot to reset the MCU, the CRC value generated by the App is compared with the CRC check value stored in the swap area of ​​the Boot. If the CRC values ​​are equal, the data is complete and the Boot is valid, and the corresponding MCU (ECU) reset operation is performed.

[0063] Finally, the UDS protocol service ID is used for message transmission, and the updated App program is loaded online through the UDS service to complete the ECU reset. During this process, Zhou Ligong's host computer flashing script is used.

[0064] In summary, the MCU online upgrade method based on the CAN bus UDS diagnostic service of the present invention has the following beneficial effects:

[0065] Complete the App program update based on the UDS service, and encapsulate the relevant algorithms into the App for burning.

[0066] Figure 9 The OTA upgrade based on the UDS service is a detailed explanation of the OTA upgrade steps based on the CAN bus UDS service, that is, the application of the above-mentioned UDS diagnostic service ID (SID). Figure 10 MCU flashing the host computer is to use the CAN box of Zhou Ligong's tool to perform online MCUAPP program upgrade on NXPS32K144 based on the UDS service OTA step.

[0067] The above disclosure is only a preferred embodiment of the present invention, and certainly cannot be used to limit the scope of the rights of the present invention. Ordinary technicians in this field can understand that all or part of the processes of the above embodiment and equivalent changes made in accordance with the claims of the present invention are still within the scope of the invention.

Claims

1. A MCU online upgrade method based on CAN bus UDS diagnostic service, characterized in that: The following steps are involved: Step 1: Select CAN bus driver; Step 2: Divide the storage area for Bootloader and App link files; In step 2, both the Bootloader and App programs partition the storage areas in Flash and SDRAM. The Bootloader program stores the App's CRC value in the swap area and compares it with the App's CRC value calculated by the bootloader. Step 3: Complete the MCU program jump from boot to App; The execution process of step 3 includes the following steps: Step 3.1: Redirect the interrupt vector table and set the address of the interrupt vector table to the starting address of the App program; Step 3.2: Redirect the main stack pointer to the address stored in the start address of the App program; Step 3.3: Redirect the address pointed to by the program counter pointer; Step 3.4: Complete the address of the corresponding App program through the function pointer; Step 4: Use the hardware watchdog to reset the MCU so that the App jumps to Boot. In step 4, when the App jumps to the Boot program, the watchdog timeout is set to 0 to reset the MCU; Program jump verification between the Bootloader and the App is implemented through CRC verification. Before the Boot program jumps to the App program, a CRC check is required. The Boot program generates a corresponding CRC-16 polynomial value and compares it with the CRC value stored in the App. If the CRC values ​​are equal, the data is complete and the App is valid, and the corresponding program jump is performed. Before the App jumps to the Boot program to reset the MCU, the CRC value generated by the App is compared with the CRC check value stored in the swap area of ​​the Boot program. If the CRC values ​​are equal, the data is complete and the Boot program is valid, and the MCU is reset. Step 5: Implement OTA online upgrade of the program through UDS diagnostic service; In step 5, use Zhou Ligong's host computer to flash the script, transmit messages through the service ID of the UDS protocol, load the updated App program online through the UDS service, and finally complete the MCU reset.

Images