Upgrading method of serial peripheral interface and vehicle-mounted domain controller

Abstract

The invention provides an upgrading method of a serial peripheral interface and a vehicle-mounted domain controller, and belongs to the technical field of vehicle-mounted OTA upgrading, the interface comprises a standard SPI signal line and a non-standard SPI signal line, and the non-standard SPI signal line comprises a TRIGGER, an ACK and a Ready. The method comprises the following steps: step S1, sending storage area drive firmware to a micro-control unit; s2, a storage area erasing instruction is sent to the micro-control unit, and data in a storage area is erased; s3, sending second firmware containing a startup loading program and an application program to the micro-control unit; and S4, configuring a storage area of the micro-control unit, and restarting the micro-control unit after firmware upgrading is completed. The method has the beneficial effects that the non-standard SPI signal line is added on the basis of the standard SPI signal line of the serial peripheral interface, so that the problem that the slave cannot actively initiate communication due to the adoption of the standard SPI interface in the OTA upgrading application of the automatic driving domain controller is solved; and meanwhile, extra hardware cost is not needed, and the upgrading efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of vehicle-mounted OTA upgrade, and in particular to a serial peripheral interface and a vehicle-mounted domain controller upgrade method. Background Art

[0002] The domain controller is one of the core components of vehicle autonomous driving. The domain controller is usually composed of a microcontroller unit (MCU) and one or more system on chip (SoC), which work together to achieve complex autonomous driving tasks.

[0003] In order to ensure the stability of domain controllers and deploy new technologies or new functions, remote upgrade technology of domain controllers is particularly important. Traditional domain controller upgrade methods, such as MCU upgrades through the controller area network (CAN) or joint test action group (JTAG) interface or Ethernet. However, the CAN interface has a slow rate, resulting in a long upgrade time. The JTAG interface can only achieve local upgrades and does not have the ability to remotely upgrade, which limits the convenience and flexibility of the upgrade. Although the Ethernet interface has a faster upgrade speed, its cost is high.

[0004] In the context of the current global economic downturn, many autonomous driving models are seeking solutions to reduce costs. At the same time, on the integrated domain controller, the capacity of the MCU's over-the-air (OTA) firmware is usually up to 4MB, which is a huge challenge for interfaces with slower transmission speeds. For example, if you choose a universal asynchronous receiver / transmitter (UART) or an internal integrated circuit (IC), 2 C) As a transmission interface, it is obviously not suitable for OTA upgrades due to the long communication time. The Serial Peripheral Interface (SPI) is usually used for communication between the host and the slave devices, such as Figure 1 As shown in the figure, the mainstream connection method is 4-wire SPI, including MOSI, MISO, SCLK and SS. It is the best choice for OTA communication due to its advantages such as fast transmission speed, moderate cost and simple integration.

[0005] However, when the traditional 4-wire SPI interface is used for OTA communication between SoC and MCU, since SPI communication is initiated by the host and cannot be initiated by the slave, when the communication between SoC and MCU needs to be initiated by the MCU, the standard SPI interface cannot meet this requirement, which limits the application of the SPI interface in OTA upgrades of autonomous driving domain controllers. Summary of the invention

[0006] In order to solve the above technical problems, the present invention provides a serial peripheral interface; on the other hand, it also provides an upgrade method of a vehicle-mounted domain controller.

[0007] The technical problem solved by the present invention can be achieved by adopting the following technical solutions:

[0008] A first aspect of the present invention is to provide a serial peripheral interface, which is used for upgrading a vehicle-mounted domain controller, and includes a standard SPI signal line and a non-standard SPI signal line, wherein the non-standard SPI signal line includes:

[0009] A first notification line (TRIGGER), used to transmit a data transmission initiation notification signal output by the master device to the slave device, so as to notify the slave device to prepare to receive data;

[0010] an ACK line (ACK), used to transmit a complete data reception ACK signal output by the slave device to the master device to confirm that the slave device has completely received the data packet;

[0011] The second notification line (Ready) is used to transmit the storage ready notification signal output by the slave device to the master device to indicate that the storage area of ​​the slave device is ready.

[0012] Preferably, the standard SPI signal line includes:

[0013] A clock signal line (SCLK), used to transmit a clock signal generated by the master device to the slave device to synchronize data transmission between the master device and the slave device;

[0014] an enable signal line (CS), used to transmit an enable signal generated by the master device to the slave device to enable the slave device;

[0015] A first data line (MOSI), serving as a data transmission channel from the master device to the slave device, and used for transmitting a data signal output by the master device to the slave device;

[0016] The second data line (MISO) serves as a data transmission channel from the slave device to the master device, and is used to transmit the data signal output by the slave device to the master device.

[0017] Preferably, the master device is a system on chip of the vehicle-mounted domain controller, and the slave device is a micro control unit of the vehicle-mounted domain controller.

[0018] A second aspect of the present invention is to provide an upgrade method for a vehicle-mounted domain controller, wherein the vehicle-mounted domain controller includes a system on chip and a micro control unit, wherein the system on chip and the micro control unit are communicatively connected via the serial peripheral interface as described above, and the upgrade method includes the following steps:

[0019] Step S1, the system on chip sends the storage area driving firmware to the micro control unit;

[0020] Step S2, the system on chip sends a storage area erase instruction to the micro control unit, and the micro control unit erases the data in the storage area according to the storage area erase instruction;

[0021] Step S3, the system on chip sends the second firmware including the boot loader and the application program to the micro control unit;

[0022] Step S4, configuring the storage area of ​​the micro control unit, and restarting the micro control unit after completing the firmware upgrade.

[0023] Preferably, before step S1, the step further includes:

[0024] Step S01, obtaining version information of the micro control unit;

[0025] Step S02, comparing the version information of the micro control unit with the version information of the package to be upgraded:

[0026] If the version information of the package to be upgraded is greater than the version information of the micro control unit, then proceed to step S1;

[0027] If the version information of the package to be upgraded is less than or equal to the version information of the micro control unit, the process ends.

[0028] Preferably, after step S1 and before step S2, the method further includes:

[0029] Step S1.1, the system on chip verifies the local storage area driver firmware and the storage area driver firmware of the micro control unit:

[0030] If the verification is passed, proceed to step S2;

[0031] If the verification fails, the storage area driver firmware is resent and the process returns to step S1.1.

[0032] Preferably, after step S3 and before step S4, the method further includes:

[0033] Step S3.1, the system on chip verifies the local second firmware and the second firmware of the micro control unit;

[0034] If the verification is passed, proceed to step S4;

[0035] If the verification fails, the second firmware is resent and the process returns to step S3.1.

[0036] Preferably, the check includes an integrity check, and the integrity check is verified using an MD5 hash value.

[0037] Preferably, the storage area is divided into two storage areas, side A and side B;

[0038] In step S4, the storage area is configured to run on the A side and perform a firmware upgrade on the B side; and

[0039] The storage area is configured to run on the B side and perform a firmware upgrade on the A side;

[0040] After the microcontroller unit is restarted, it switches to the opposite side where the upgrade is successful.

[0041] Preferably, the second firmware is divided into a plurality of data blocks, each of which is allocated with indication information, and the indication information is used to indicate whether the upgrade process is continuous;

[0042] The firmware upgrade process of step S4 includes:

[0043] The micro control unit detects whether the indication information is continuous;

[0044] After detecting the discontinuous indication information, sending indication error information to the system on chip;

[0045] After receiving the error indication information, the system on chip retransmits the data block.

[0046] The advantages or beneficial effects of the technical solution of the present invention are:

[0047] The present invention adds non-standard SPI signal lines, such as a first notification line (TRIGGER), an answer line (ACK), and a second notification line (Ready), on the basis of the standard SPI signal lines of the serial peripheral interface, thereby solving the problem that the slave cannot actively initiate communication due to the use of a standard SPI interface in the OTA upgrade application of the autonomous driving domain controller; at the same time, the vehicle-mounted domain controller upgrade uses its own SPI interface for communication, and no additional hardware cost is required, so that fast and cost-effective firmware upgrades can be achieved between the SoC and the MCU, further improving the upgrade efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 It is a communication connection diagram of a 4-wire serial peripheral interface in the prior art;

[0049] Figure 2 A communication connection diagram of a 7-wire serial peripheral interface in a preferred embodiment of the present invention;

[0050] Figure 3 A timing diagram of a host initiating communication in a preferred embodiment of the present invention;

[0051] Figure 4 A timing diagram of a slave initiating communication in a preferred embodiment of the present invention;

[0052] Figure 5 A schematic diagram of a flow chart of an upgrade method in a preferred embodiment of the present invention;

[0053] Figure 6 A schematic diagram of a process of version comparison in a preferred embodiment of the present invention;

[0054] Figure 7 A schematic diagram of a flow chart of storage area driver firmware verification in a preferred embodiment of the present invention;

[0055] Figure 8 A schematic diagram of a flow chart of a second firmware verification process including a boot loader and an application program in a preferred embodiment of the present invention;

[0056] Fig. 9 A schematic diagram of a storage area in a preferred embodiment of the present invention;

[0057] Fig.10 The figure is a flow chart of continuity detection during the upgrade process in a preferred embodiment of the present invention. DETAILED DESCRIPTION

[0058] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0059] It should be noted that, in the absence of conflict, the embodiments of the present invention and the features in the embodiments may be combined with each other.

[0060] The present invention will be further described below in conjunction with the accompanying drawings and specific embodiments, but they are not intended to limit the present invention.

[0061] In view of different application scenarios and data transmission requirements, there are multiple options for inter-chip communication in the vehicle domain controller, such as:

[0062] Universal Asynchronous Receiver / Transmitter (UART): UART communication has the advantages of simple implementation and low cost, and is suitable for application scenarios where data rate requirements are not high.

[0063] Inter-Integrated Circuit (I 2 C):I 2 C bus has the characteristics of low cost, simple structure, and support for multi-slave addressing, and is suitable for low-speed communication applications that interconnect multiple sensors or devices.

[0064] Serial Peripheral Interface (SPI): The SPI bus is suitable for high-speed data transmission scenarios because of its high speed and support for full-duplex communication.

[0065] Ethernet / CAN: The advantages are high transmission rate and long transmission distance, but the cost is high.

[0066] In the current situation where the world economy is in a downturn, self-driving models are generally implementing cost reduction plans. In this context, the embodiment of the present invention selects the SPI bus as the OTA communication channel between the SoC and the MCU.

[0067] In particular, SoC and MCU support SPI control modules. Therefore, choosing SPI communication mode does not require additional hardware costs. In addition, SPI communication speed is second only to Ethernet and is superior to other communication media such as CAN, I 2 C, UART, JTAG, etc., can meet the data transmission rate requirements of OTA updates.

[0068] The SPI bus is usually used as a communication channel between a master device (or host Master) and a slave device (or slave Slave). The mainstream connection method is 4-wire SPI, including:

[0069] MOSI (Master Out Slave In): The signal line through which the master device sends data and the slave device receives data.

[0070] MISO (Master In Slave Out): The signal line through which the slave device sends data and the master device receives data.

[0071] SCLK (Serial Clock): A clock signal generated by a master device and used to synchronize data transmission.

[0072] SS (Slave Select): Select the signal line of the slave device, low level is valid.

[0073] In the traditional SPI communication process, the host selects and communicates with the slave device by controlling the clock signal and chip select signal, and the slave device transmits and receives data according to the host's instructions.

[0074] It can be seen that the traditional SPI communication method is initiated by the host, not by the slave. However, in the OTA communication scenario between SoC and MCU, the communication may be initiated by the SoC or the MCU. Therefore, the ordinary standard 4-wire SPI communication method cannot meet the OTA communication requirements.

[0075] See also Figure 2 In a preferred embodiment of the present invention, based on the above problems existing in the prior art, a serial peripheral interface is provided, which is applied to upgrade the vehicle-mounted domain controller, including a standard SPI signal line and a non-standard SPI signal line, and the non-standard SPI signal line includes:

[0076] A first notification line (TRIGGER), used to transmit a data transmission initiation notification signal output by the master device to the slave device, so as to notify the slave device to prepare to receive data;

[0077] The ACK line is used to transmit the complete data reception acknowledgment signal output by the slave device to the master device to confirm that the slave device has completely received the data packet;

[0078] The second notification line (Ready) is used to transmit the storage ready notification signal output by the slave device to the master device to indicate that the storage area of ​​the slave device is ready.

[0079] Specifically, in view of the problem that when the SPI interface is used as the communication method between the SoC and the MCU in the prior art, the traditional 4-wire SPI is used for the OTA communication solution between the SoC and the MCU. The embodiment of the present invention adopts a 7-wire SPI connection method, which adds 3 lines on the basis of the standard 4-wire SPI connection method, namely, a first notification line (TRIGGER), an answer line (ACK), and a second notification line (Ready), so that the Slave end informs the Master end when it needs to actively send data, and then the Master end initiates communication.

[0080] As a preferred embodiment, the standard SPI signal line includes:

[0081] A clock signal line (SCLK) is used to transmit the clock signal generated by the master device to the slave device to synchronize the data transmission between the master device and the slave device;

[0082] An enable signal line (CS), used to transmit an enable signal generated by the master device to the slave device to enable the slave device;

[0083] A first data line (MOSI), serving as a data transmission channel from a master device to a slave device, for transmitting a data signal output by the master device to the slave device;

[0084] The second data line (MISO) serves as a data transmission channel from the slave device to the master device, and is used to transmit the data signal output by the slave device to the master device.

[0085] The signal line definitions and meanings of the 7-wire SPI proposed in the embodiment of the present invention are shown in Table 1 below.

[0086] Table 1 Definition and meaning of 7-wire SPI signal lines

[0087] Serial number definition meaning 1 SCLK The clock signal is generated by the master device and provided to the slave device 2 CS Slave device enable signal, controlled by the master device 3 MOSI Master device data output, slave device data input 4 MISO Master input, slave output 5 TRIGGER Master device data transmission initiation notification 6 ACK Complete data reception response from the device 7 Ready Bufferready notification from device

[0088] As a preferred implementation, the master device is a system on chip (SoC) of the vehicle-mounted domain controller, and the slave device is a microcontroller unit (MCU) of the vehicle-mounted domain controller.

[0089] exist Figure 3 The timing diagram shown shows the data transmission process between the SoC (as the host) and the MCU (as the slave) in the embodiment of the present invention. Figure 3 The five rectangular boxes in the figure represent five transmission steps, as follows:

[0090] Step 1.1: See Figure 3 In the rectangular box 1, when the SoC needs to send data to the MCU, the SoC will first pull down (or pull up, depending on the circuit design) the GPIO pin of the TRIGGER signal line.

[0091] This GPIO signal is an interrupt signal for the MCU, which is used to notify the MCU: "The SoC is about to send data, please be prepared to receive it."

[0092] Step 1.2: See Figure 3 In the rectangular box 2, after receiving the interrupt signal of the TRIGGER pin, the MCU will check its system status. If the system status is normal, the MCU will pull down (or pull up) the GPIO pin of the Ready signal line as a response to the SoC, indicating that the MCU is ready to receive data.

[0093] The Ready signal is also an interrupt signal for the SoC, which is used to notify the SoC: "The MCU is ready to proceed to the next step."

[0094] Step 1.3: See Figure 3In the rectangular box 3, after the SoC detects the interrupt signal on the Ready pin, it will immediately start to provide CLOCK and CS signals. The CLOCK signal is used to synchronize data transmission, while the CS signal is used to select the MCU currently communicating with the SoC.

[0095] If the SoC fails to provide CLOCK and CS signals within 2 seconds, the SoC will trigger a timeout error, indicating that the data transfer failed to start on time.

[0096] Step 1.4: See Figure 3 In rectangular box 4, if the SoC provides CLOCK and CS signals within 2 seconds, data transmission can begin.

[0097] In order to ensure the stability of transmission, the maximum data length of a single transmission is defined as 256 bytes in the embodiment of the present invention. If more than 256 bytes of data need to be transmitted, both ends need to negotiate a data fragmentation mechanism to ensure that the data can be transmitted correctly and completely.

[0098] Step 1.5: See Figure 3 After the data transmission is completed, the MCU will trigger an ACK signal, indicating that the MCU has successfully received all the data sent by the SoC.

[0099] exist Figure 4 The timing diagram shown shows the data transmission process between the MCU (as the host) and the SoC (as the slave) in the embodiment of the present invention. Figure 4 The three rectangular boxes in the figure represent three transmission steps, as follows:

[0100] Step 2.1: See Figure 4 When the MCU needs to actively send data to the SoC, the MCU will first trigger the Ready signal to tell the SoC: "I am going to start sending data, please provide CLOCK and CS signals."

[0101] Step 2.2: See Figure 4 In rectangular box 2, after receiving the Ready signal, the SoC starts to provide CLOCK and CS signals; if the SoC fails to provide these signals within 2 seconds, the MCU will trigger a timeout error.

[0102] Step 2.3: See Figure 4 In rectangular box 3, if the SoC provides CLOCK and CS signals within 2 seconds, the MCU can start transmitting data.

[0103] Through the above signal interaction and timing control, a stable and reliable communication link is established between the SoC and the MCU in the embodiment of the present invention. This communication link not only supports the transmission of data from the SoC to the MCU, but also supports the transmission of data from the MCU to the SoC, thereby realizing two-way data communication.

[0104] The present invention also provides an upgrade method for a vehicle-mounted domain controller, wherein the vehicle-mounted domain controller includes a system on chip (SoC) and a microcontroller unit (MCU), wherein the system on chip (SoC) and the microcontroller unit (MCU) are communicatively connected via the above-mentioned serial peripheral interface, and the upgrade method includes the following steps:

[0105] Step S1, the system on chip SoC sends the storage area driver (Flash Driver) firmware to the micro control unit MCU;

[0106] Step S2, the system on chip SoC sends a storage area erase instruction to the micro control unit MCU, and the micro control unit MCU erases the data in the storage area according to the storage area erase instruction;

[0107] Step S3, the system on chip SoC sends the second firmware including the bootloader and the application (Bootloader+APP) to the microcontroller unit MCU;

[0108] Step S4, configuring the storage area of ​​the micro control unit MCU, and restarting the micro control unit MCU after completing the firmware upgrade.

[0109] Specifically, in this embodiment, 7-wire SPI is used as the communication method between the system on chip SoC and the microcontroller unit MCU, which solves the problem that the slave cannot actively initiate communication due to the standard SPI interface in the OTA upgrade application of the autonomous driving domain controller. This enables the MCU to actively initiate communication with the SoC while the SoC can actively initiate communication with the MCU, thus being suitable for firmware upgrades of the vehicle-mounted domain controller.

[0110] As a preferred embodiment, before step S1, the method further includes:

[0111] Step S01, obtaining version information of the microcontroller unit MCU;

[0112] Step S02, comparing the version information of the microcontroller unit MCU with the version information of the package to be upgraded:

[0113] If the version information of the package to be upgraded is greater than the version information of the microcontroller unit MCU, then go to step S1;

[0114] If the version information of the package to be upgraded is less than or equal to the version information of the microcontroller unit MCU, the process ends.

[0115] Specifically, during the upgrade process of the vehicle domain controller, first, the version information of the microcontroller unit (MCU) is obtained through the SPI interface. This information is usually stored in the non-volatile memory of the MCU, including key data such as version number and release date.

[0116] Then, the obtained MCU version information is compared with the version information in the firmware package to be upgraded. If the version information of the package to be upgraded is a new version, it indicates that there is an update, and the system enters the preparation for upgrading; if the version information of the package to be upgraded is less than or equal to the current version information of the MCU, it means that the current MCU firmware is the latest version or the package to be upgraded is an old version, and there is no need to upgrade, and the upgrade process ends immediately.

[0117] As a preferred embodiment, after step S1 and before step S2, the method further includes:

[0118] Step S1.1, the system on chip SoC verifies the local storage area driver firmware and the storage area driver firmware of the microcontroller unit MCU:

[0119] If the verification passes, proceed to step S2;

[0120] If the verification fails, the storage area driver firmware is resent and the process returns to step S1.1.

[0121] As a preferred implementation, the verification includes an integrity check, and the integrity check is verified using an MD5 hash value.

[0122] Specifically, in this embodiment, the system on chip (SoC) verifies the driver firmware in its local storage area and the driver firmware in the MCU storage area. The verification process includes comparing the MD5 hash values ​​of the two to verify the integrity and consistency of the firmware.

[0123] If the verification passes, that is, the MD5 values ​​match, it means that the firmware is not damaged and is correct;

[0124] If the verification fails, that is, the MD5 value does not match, it indicates that the firmware may be damaged or transmitted incorrectly. The storage area driver firmware will be resent and re-verified to ensure the correctness of the firmware.

[0125] As a preferred embodiment, after step S3 and before step S4, the method further includes:

[0126] Step S3.1, the system on chip SoC verifies the local second firmware and the second firmware of the microcontroller unit MCU;

[0127] If the verification passes, proceed to step S4;

[0128] If the verification fails, the second firmware is resent and the process returns to step S3.1.

[0129] Specifically, in this embodiment, the SoC verifies the local Boot+APP firmware and the corresponding Boot+APP firmware in the MCU, and the verification also uses the MD5 hash value for integrity verification.

[0130] If the verification passes, it confirms that the firmware is complete and correct; if the verification fails, it indicates that there is a problem with the firmware. The system will resend the Boot+APP firmware and re-verify until the firmware verification passes, ensuring the correctness and integrity of all key firmware during the upgrade process.

[0131] As a preferred embodiment, the storage area is divided into two storage areas, namely, side A and side B.

[0132] In this embodiment, the storage area can be a flash memory Flash. Of course, but not limited to this, other memories can also be used, specifically selected according to actual needs.

[0133] Specifically, in this embodiment, by designing the Flash storage structure of the MCU into an A / B dual partition type, it is ensured that the MCU supports remote upgrades and supports rolling back to a previous version when there is a problem with the firmware.

[0134] The A / B dual partition design means that the MCU's Flash storage is divided into two independent areas: Area A and Area B. The two areas are of the same size and are used to store different firmware versions.

[0135] One of the storage areas in area A and area B is used as the currently running firmware version area, and the other storage area is used as a backup firmware version area or for storing a new firmware version.

[0136] As a preferred embodiment, in step S4, the storage area is configured to run on surface A and perform a firmware upgrade on surface B; and

[0137] The storage area is configured to run on side B and perform firmware upgrades on side A;

[0138] After the microcontroller unit MCU is restarted, it switches to the opposite side of the upgrade success.

[0139] Specifically, the OTA protocol of the embodiment of the present invention also supports switching to the opposite side where the upgrade is successful after the system is restarted.

[0140] Specifically, the OTA protocol of the embodiment of the present invention supports upgrading the B side under the A side, and upgrading the A side under the B side, thereby ensuring the continuity of the system.

[0141] In the embodiment of the present invention, area A is used as the current operation area and area B is used as the backup area.

[0142] During the remote upgrade process, the MCU receives the new firmware version through the SPI communication interface, and the received firmware is stored in area B. At this time, the firmware in area A is still running to ensure the continuity of the system.

[0143] After storing the new firmware, the MCU will verify it to ensure its integrity and correctness. If the new firmware is verified successfully, the MCU will reset and load and run the new firmware from area B. At this time, area A becomes

[0144] If a new firmware version is received, the received firmware is stored in area A.

[0145] If the MCU detects a problem with the new firmware, such as crash, malfunction, etc., the MCU will automatically reset and load and run the previous firmware version from zone A to achieve rollback.

[0146] As a preferred implementation, the second firmware is divided into a plurality of data blocks Data_Block, each data block Data_Block is allocated with indication information SN, and the indication information SN is used to indicate whether the upgrade process is continuous;

[0147] The firmware upgrade process of step S4 includes:

[0148] Step S401, the micro control unit MCU detects whether the indication information SN is continuous;

[0149] Step S402, after detecting discontinuous indication information SN, sending error indication information SN_ERROR to the system on chip;

[0150] Step S403 , after receiving the SN_ERROR information indicating an error, the system on chip Soc retransmits the data block Data_Block.

[0151] Exemplarily, each communication protocol format may be as shown in Table 2 below.

[0152] Table 2 Communication protocol format

[0153] Length SourceID DestID SN CMD CMDcontents 2 bytes 1 byte 1 byte 2 bytes 1 byte N bytes

[0154] The frame structure defined in Table 2 above contains the following key fields:

[0155] Length: represents the byte length of the entire frame. The maximum length of Length+Source ID+Dest ID+SN+CMD type+CMD content does not exceed 256 bytes.

[0156] Source ID: A unique identifier of the sender, used to track the source of the data.

[0157] Dest ID: A unique identifier on the receiving end that is used to ensure that data is correctly sent to the intended destination.

[0158] SN: The indication information is a 16-bit value ranging from 0x0000 to 0xFFFF. The SN field starts counting from 0. Each time a frame of data is sent, the frame count of the indication information increases by 1. When it reaches 0xFFFF, it will start counting again from 0x0000.

[0159] The data is in high byte first and low byte last.

[0160] CMD type: Command type field, used to indicate the command type carried in the frame.

[0161] CMD content: Command content field, which contains data or information related to a specific command.

[0162] Furthermore, the SN fields on the SoC side and the MCU side have nothing to do with each other and each independently starts counting from 0.

[0163] The SN field is only used to verify whether the upgrade process is continuous, not to verify the data continuity during Data_Block transmission. Data_Block has its own continuity verification byte.

[0164] When the MCU receives a frame from the SoC, it checks whether the SN field is continuous. If a discontinuous SN field is detected, the MCU responds with an SN_ERROR error message.

[0165] If the SoC receives an SN_ERROR error message sent by the MCU, the SoC will not reply but directly retransmit the frame to ensure the correctness and continuity of the data.

[0166] The OTA protocol of the embodiment of the present invention adopts a question-and-answer type, and its upgrade process includes the following steps:

[0167] First, get the MCU version.

[0168] The MCU returns its own firmware version information to compare the MCU firmware version information with the version information of the local pre-upgrade package. If the upgrade package version is newer, then the upgrade continues; otherwise, the upgrade process is stopped.

[0169] Exemplarily, the message format for obtaining the MCU version may be as shown in Table 3 below.

[0170] Table 3 Message format for obtaining MCU version

[0171]

[0172]

[0173] Then, send the Flash Driver firmware to the MCU.

[0174] Since the MCU firmware capacity is relatively small, the Flash program is not integrated into the Flash. Therefore, the FlashDriver firmware needs to be sent to the MCU, and the MCU stores the Flash Driver firmware in the memory.

[0175] Exemplarily, the message format of the communication sequence of the Flash Driver firmware sending step may be as shown in Table 4 below.

[0176] Table 4 Message format of the communication sequence of the Flash Driver firmware sending steps

[0177]

[0178]

[0179] Then, perform MD5 value verification on the local Flash Driver firmware and the Flash Driver firmware on the MCU side.

[0180] If the verification fails, resend the Flash Driver firmware to the MCU.

[0181] Exemplarily, the message format of the communication sequence of the Flash Driver firmware MD5 value verification step may be as shown in Table 5 below.

[0182] Table 5 Message format of the communication sequence of the Flash Driver firmware MD5 value verification step

[0183]

[0184] Then, a Flash erase command is sent to erase the data on the side (side A or side B) where data is to be written.

[0185] Exemplarily, the message format of the communication sequence of the Flash erase instruction sending step may be as shown in Table 6 below.

[0186] Table 6 Message format of the communication sequence of the Flash erase command sending step

[0187]

[0188] Then, send the Boot+APP firmware to the MCU.

[0189] Exemplarily, the message format of the communication sequence of the Boot+APP firmware sending step may be as shown in Table 7 below.

[0190] Table 7 Message format of the communication sequence of the Boot+APP firmware sending steps

[0191]

[0192]

[0193] Then, perform MD5 value verification on the local Boot+APP firmware and the Boot+APP firmware on the MCU side.

[0194] If the verification fails, resend the Boot+APP firmware to the MCU.

[0195] Exemplarily, the message format of the communication sequence of the Boot+APP firmware MD5 verification step may be as shown in Table 8 below.

[0196] Table 8 Message format of the communication sequence of the Boot+APP firmware MD5 verification step

[0197]

[0198] Finally, configure the surface on which the system will run.

[0199] For example, if the firmware upgrade is performed on the B side, then in this step, switch to the B side and perform the firmware upgrade on the A side. Similarly, if the firmware upgrade is performed on the A side, then in this step, switch to the A side and perform the firmware upgrade on the B side.

[0200] After the upgrade is successful, reboot the system.

[0201] Exemplarily, the message format of the communication sequence between the slice and the restart step may be as shown in Table 9 below.

[0202] Table 9 Message format of the communication sequence between the slice and the restart step

[0203]

[0204] After the system restarts, switch to the opposite side where the upgrade is successful, and the MCU version upgrade is completed.

[0205] The advantages or beneficial effects of adopting the above technical solution are: the present invention solves the problem that the slave cannot actively initiate communication due to the use of the standard SPI interface in the OTA upgrade application of the autonomous driving domain controller by adding non-standard SPI signal lines, such as the first notification line (TRIGGER), the answer line (ACK), and the second notification line (Ready), on the basis of the standard SPI signal lines of the serial peripheral interface; at the same time, the vehicle-mounted domain controller upgrade uses its own SPI interface for communication, and no additional hardware cost is required, so that fast and cost-effective firmware upgrades can be achieved between the SoC and the MCU, further improving the upgrade efficiency.

[0206] The above are only preferred embodiments of the present invention, and are not intended to limit the implementation methods and protection scope of the present invention. Those skilled in the art should be aware that all solutions obtained by equivalent substitutions and obvious changes made using the contents of this specification and illustrations should be included in the protection scope of the present invention.

Claims

1. A serial peripheral interface, characterized in that: The serial peripheral interface is used to upgrade the vehicle-mounted domain controller, including a standard SPI signal line and a non-standard SPI signal line, and the non-standard SPI signal line includes: A first notification line (TRIGGER), used to transmit a data transmission initiation notification signal output by the master device to the slave device, so as to notify the slave device to prepare to receive data; an ACK line (ACK), used to transmit a complete data reception ACK signal output by the slave device to the master device to confirm that the slave device has completely received the data packet; The second notification line (Ready) is used to transmit the storage ready notification signal output by the slave device to the master device to indicate that the storage area of ​​the slave device is ready.

2. The serial peripheral interface according to claim 1, characterized in that: The standard SPI signal lines include: A clock signal line (SCLK), used to transmit a clock signal generated by the master device to the slave device to synchronize data transmission between the master device and the slave device; an enable signal line (CS), used to transmit an enable signal generated by the master device to the slave device to enable the slave device; A first data line (MOSI), serving as a data transmission channel from the master device to the slave device, and used for transmitting a data signal output by the master device to the slave device; The second data line (MISO) serves as a data transmission channel from the slave device to the master device, and is used to transmit the data signal output by the slave device to the master device.

3. The serial peripheral interface according to claim 1, characterized in that: The master device is a system on chip of the vehicle-mounted domain controller, and the slave device is a micro control unit of the vehicle-mounted domain controller.

4. A method for upgrading a vehicle-mounted domain controller, characterized in that: The vehicle-mounted domain controller includes a system on chip and a micro control unit, the system on chip and the micro control unit are communicatively connected via a serial peripheral interface according to any one of claims 1 to 3, and the upgrade method includes the following steps: Step S1, the system on chip sends the storage area driving firmware to the micro control unit; Step S2, the system on chip sends a storage area erase instruction to the micro control unit, and the micro control unit erases the data in the storage area according to the storage area erase instruction; Step S3, the system on chip sends the second firmware including the boot loader and the application program to the micro control unit; Step S4, configuring the storage area of ​​the micro control unit, and restarting the micro control unit after completing the firmware upgrade.

5. The upgrading method according to claim 4, characterized in that: Before step S1, the following steps are also included: Step S01, obtaining version information of the micro control unit; Step S02, comparing the version information of the micro control unit with the version information of the package to be upgraded: If the version information of the package to be upgraded is greater than the version information of the micro control unit, then proceed to step S1; If the version information of the package to be upgraded is less than or equal to the version information of the micro control unit, the process ends.

6. The upgrading method according to claim 4, characterized in that: After step S1 and before step S2, the following further comprises: Step S1.1, the system on chip verifies the local storage area driver firmware and the storage area driver firmware of the micro control unit: If the verification is passed, proceed to step S2; If the verification fails, the storage area driver firmware is resent and the process returns to step S1.

1.

7. The upgrading method according to claim 4, characterized in that: After step S3 and before step S4, the following steps are also included: Step S3.1, the system on chip verifies the local second firmware and the second firmware of the micro control unit; If the verification is passed, proceed to step S4; If the verification fails, the second firmware is resent and the process returns to step S3.

1.

8. The upgrading method according to claim 6 or 7, characterized in that: The verification includes an integrity check, and the integrity check is verified using an MD5 hash value.

9. The upgrading method according to claim 4, characterized in that: The storage area is divided into two storage areas, side A and side B; In the step S4, the storage area is configured to run on the A surface and perform a firmware upgrade on the B surface; as well as The storage area is configured to run on the B side and perform a firmware upgrade on the A side; After the microcontroller unit is restarted, it switches to the opposite side where the upgrade is successful.

10. The upgrading method according to claim 4, characterized in that: The second firmware is divided into a plurality of data blocks, each of the data blocks is allocated with indication information, and the indication information is used to indicate whether the upgrade process is continuous; The firmware upgrade process of step S4 includes: The micro control unit detects whether the indication information is continuous; After detecting the discontinuous indication information, sending indication error information to the system on chip; After receiving the error indication information, the system on chip retransmits the data block.

Images