A APP integrity checking method based on UDS-FBL

Abstract

The present invention discloses an APP integrity check method based on UDS-FBL. A request message related to flashing is sent through a UDS unified diagnostic service. A bootloader program and binary data corresponding to an application are generated and downloaded, and the binary data are stored in a ROM space of a controller, and a Bootloader programming mode is entered. A FALSHDRIVER is downloaded through a diagnostic service, and then the application is erased through the FALSHDRIVER. The Bootloader program writes the application valid flag bit as invalid, and then erases the area corresponding to the application in the ROM space. Then, new application binary data is written into the ROM space corresponding to the application. The Bootloader program performs a new application integrity check. If the check is successful, the new application validity is set to valid, and the controller is restarted and enters the new application.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing, and in particular to an APP integrity checking method based on UDS-FBL. Background Art

[0002] With the continuous innovation of automotive electronic technology, more and more automotive electronic devices need to upgrade software based on the original hardware; at the same time, since the development of embedded software cannot avoid bugs that were not detected during the design and testing phase, the upgrade of application software and the repair of problems require the electronic devices themselves to have the ability to apply software.

[0003] The common method of upgrading the software of automotive electronic devices is to use the diagnostic commands in the unified diagnostic service protocol IOS-14229 to send a series of diagnostic requests through the diagnostic instrument / refresh instrument connected to the vehicle network, transfer the new software from the external device to the controller, and guide the controller to upgrade the software. However, in the current solution, from the generation of the application APP to the completion of the upgrade to the control unit, it needs to be transmitted and saved multiple times, and there is no guarantee whether the APP has been tampered with or some data has been lost. Summary of the invention

[0004] In view of the above-mentioned deficiencies in the prior art, the technical problem to be solved by the present invention is: how to provide an APP integrity checking method based on UDS-FBL to reduce the risk of APP being tampered with or data loss when the application is refreshed.

[0005] In order to solve the above technical problems, the present invention adopts the following technical solutions:

[0006] An APP integrity check method based on UDS-FBL, characterized by comprising:

[0007] Send flash-related request messages through the UDS unified diagnostic service;

[0008] Generate and download binary data corresponding to the bootloader program, and store the binary data corresponding to the bootloader program in the ROM space of the controller, which is a non-programmable area;

[0009] Generate and download binary data corresponding to the application, and store the binary data corresponding to the application in the ROM space of the controller, which is a programmable area that is erased and written when the program is flashed;

[0010] The UDS unified diagnostic service supports default, extended and programming modes; the Bootloader program includes a UDS diagnostic protocol layer, a data transmission layer and a CAN driver layer, which can implement a complete diagnostic protocol stack, which supports default, extended and programming modes; the application includes a diagnostic protocol stack, which supports default and extended modes; the application sets an external programming request flag to execute a diagnostic request command for switching the programming diagnostic mode;

[0011] When a diagnostic request command for switching programming diagnostic mode is received in the application program, the external programming request flag is set, the controller is restarted, and the Bootloader program judges the external programming request flag and then enters the Bootloader programming mode;

[0012] After entering the Bootloader programming mode, the FALSHDRIVER is received through the diagnostic service download, and then the application is erased through the FALSHDRIVER. The Bootloader program writes the application valid flag bit to invalid, and then erases the area corresponding to the application in the ROM space;

[0013] The binary data corresponding to the application is set to A1. C1 can be obtained through CRC calculation. C1 is spliced ​​according to the storage format of A1, bin, S19 or hex, and C1 is spliced ​​behind A1 to form new application binary data A2. Then the new application binary data is written into the ROM space corresponding to the application.

[0014] The Bootloader program performs an integrity check on the new application. If the check succeeds, the validity of the new application is set to valid, and the controller restarts and enters the new application.

[0015] As an optimization, the controller's ROM space is divided into a Bootloader program area and an application area. The Bootloader program area stores the binary executable code compiled from the bootloader source code. When the controller is powered on or reset, the software will jump to the entrance of its area after completing the self-test; the application area stores the binary executable code compiled from the application source code. The bootloader program can erase and write the ROM in this area. After the bootloader program is executed, it will jump to the entrance of this area.

[0016] As an optimization, after receiving the new application binary data A2, the bootloader program stores A1 and C1 into the ROM space and RAM space respectively.

[0017] As an optimization, after receiving the new application binary data A2, the bootloader program determines whether A2 is the last 4 bytes. If so, A2 is stored in the RAM space, otherwise A2 is stored in the ROM space, and CRC calculation is performed on A2 in the ROM space to obtain a new CRC value C2. C1 and C2 are compared. If they are the same, the new application valid flag is written as valid.

[0018] In summary, the beneficial effects of the present invention are: the present invention has the following advantages:

[0019] (1) The verification code C2 is added when the APP program is generated, and is finally checked by the bootloader after being flashed into the ECU; this ensures that any data tampering or loss during the entire transmission process from the application program to the MCU can be detected;

[0020] (2) The bootloader only stores A1 in ROM and C1 in RAM. After the controller restarts, the data in RAM is automatically abandoned. C1 will not affect the execution of the original application. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to make the purpose, technical solution and advantages of the invention more clear, the present invention will be further described in detail below with reference to the accompanying drawings, in which:

[0022] Figure 1 It is a schematic diagram of the image of the Bootloader program and the application program in the controller memory of the present invention;

[0023] Figure 2 A schematic diagram of generating a new application in the present invention;

[0024] Figure 3 This is a schematic diagram of the download refresh data flow in the present invention;

[0025] Figure 4 It is a schematic diagram of the program startup steps in the present invention;

[0026] Figure 5 It is a schematic diagram of the downloading and flashing steps in the present invention. DETAILED DESCRIPTION

[0027] The present invention will be further described in detail below in conjunction with the accompanying drawings.

[0028] like Figures 1 to 5 As shown, a method for checking APP integrity based on UDS-FBL in this specific implementation includes:

[0029] Send flash-related request messages through the UDS unified diagnostic service;

[0030] Generate and download binary data corresponding to the bootloader program, and store the binary data corresponding to the bootloader program in the ROM space of the controller, which is a non-programmable area;

[0031] Generate and download binary data corresponding to the application, and store the binary data corresponding to the application in the ROM space of the controller, which is a programmable area that is erased and written when the program is flashed;

[0032] The UDS unified diagnostic service supports default, extended and programming modes; the Bootloader program includes a UDS diagnostic protocol layer, a data transmission layer and a CAN driver layer, which can implement a complete diagnostic protocol stack, which supports default, extended and programming modes; the application includes a diagnostic protocol stack, which supports default and extended modes; the application sets an external programming request flag to execute a diagnostic request command for switching the programming diagnostic mode;

[0033] When a diagnostic request command for switching programming diagnostic mode is received in the application program, the external programming request flag is set, the controller is restarted, and the Bootloader program judges the external programming request flag and then enters the Bootloader programming mode;

[0034] After entering the Bootloader programming mode, the FALSHDRIVER is received through the diagnostic service download, and then the application is erased through the FALSHDRIVER. The Bootloader program writes the application valid flag bit to invalid, and then erases the area corresponding to the application in the ROM space;

[0035] The binary data corresponding to the application is set to A1. C1 can be obtained through CRC calculation. C1 is spliced ​​according to the storage format of A1, bin, S19 or hex, and C1 is spliced ​​behind A1 to form new application binary data A2. Then the new application binary data is written into the ROM space corresponding to the application.

[0036] The Bootloader program performs an integrity check on the new application. If the check succeeds, the validity of the new application is set to valid, and the controller restarts and enters the new application.

[0037] In this specific implementation, the ROM space of the controller is divided into a Bootloader program area and an application program area. The Bootloader program area stores the binary executable code compiled from the bootloader source code. When the controller is powered on or reset, the software will jump to the entrance of its area after completing the self-test; the application program area stores the binary executable code compiled from the application source code. The bootloader program can erase and write the ROM in this area. After the bootloader program is executed, it will jump to the entrance of this area.

[0038] In this specific implementation, after receiving the new application binary data A2, the bootloader program stores A1 and C1 into the ROM space and RAM space respectively.

[0039] In this specific implementation, after receiving the new application binary data A2, the bootloader program determines whether A2 is the last 4 bytes. If so, A2 is stored in the RAM space, otherwise A2 is stored in the ROM space, and CRC calculation is performed on A2 in the ROM space to obtain a new CRC value C2. C1 and C2 are compared, and if they are the same, the new application valid flag is written as valid.

[0040] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described with reference to the preferred embodiments of the present invention, it should be understood by those skilled in the art that various changes may be made in form and details without departing from the spirit and scope of the present invention as defined in the appended claims.

Claims

1. A method for checking APP integrity based on UDS-FBL, characterized by: include: Send flash-related request messages through the UDS unified diagnostic service; Generate and download binary data corresponding to the bootloader program, and store the binary data corresponding to the bootloader program in the ROM space of the controller, which is a non-programmable area; Generate and download binary data corresponding to the application, and store the binary data corresponding to the application in the ROM space of the controller, which is a programmable area that is erased and written when the program is flashed; The UDS unified diagnostic service supports default, extended and programming modes; the Bootloader program includes a UDS diagnostic protocol layer, a data transmission layer and a CAN driver layer, which can implement a complete diagnostic protocol stack, which supports default, extended and programming modes; the application includes a diagnostic protocol stack, which supports default and extended modes; the application sets an external programming request flag to execute a diagnostic request command for switching the programming diagnostic mode; When a diagnostic request command for switching programming diagnostic mode is received in the application program, the external programming request flag is set, the controller is restarted, and the Bootloader program judges the external programming request flag and then enters the Bootloader programming mode; After entering the Bootloader programming mode, the FALSHDRIVER is received through the diagnostic service download, and then the application is erased through the FALSHDRIVER. The Bootloader program writes the application valid flag bit to invalid, and then erases the area corresponding to the application in the ROM space; The binary data corresponding to the application is set to A1. C1 can be obtained through CRC calculation. C1 is spliced ​​according to the storage format of A1, bin, S19 or hex, and C1 is spliced ​​behind A1 to form new application binary data A2. Then the new application binary data is written into the ROM space corresponding to the application. The Bootloader program performs a new application integrity check. If the check succeeds, the new application validity is set to valid, and the controller restarts and enters the new application. The ROM space of the controller is divided into the Bootloader program area and the application program area. The Bootloader program area stores the binary executable code compiled from the bootloader source code. When the controller is powered on or reset, the software will jump to the entrance of its area after completing the self-test; the application program area stores the binary executable code compiled from the application source code. The bootloader program can erase and write the ROM in this area. After the bootloader program is executed, it will jump to the entrance of this area. After receiving the new application binary data A2, the bootloader program stores A1 and C1 into the ROM space and RAM space respectively; After receiving the new application binary data A2, the bootloader program determines whether A2 is the last 4 bytes. If so, A2 is stored in the RAM space, otherwise A2 is stored in the ROM space, and CRC calculation is performed on A2 in the ROM space to obtain a new CRC value C2. C1 and C2 are compared. If they are the same, the new application valid flag is written as valid.

Images