CN113377384A

CN113377384A - Program burning method and device, vehicle-mounted terminal and medium

Info

Publication number: CN113377384A
Application number: CN202110625906.2A
Authority: CN
Inventors: 周凯伦; 曹斌
Original assignee: Neusoft Reach Automotive Technology Shenyang Co Ltd
Current assignee: Neusoft Reach Automotive Technology Shenyang Co Ltd
Priority date: 2021-06-04
Filing date: 2021-06-04
Publication date: 2021-09-10

Abstract

The application discloses a program burning method, a program burning device, a vehicle-mounted terminal and a medium, which are applied to the technical field of automobiles and are used for solving the problem that in the prior art, the upgrading of MCU bottom layer drive firmware cannot be realized in an Ethernet burning MCU mode because an MCU does not have a network card device. The method specifically comprises the following steps: by utilizing Ethernet communication between the diagnosis equipment and the SOC in the vehicle-mounted terminal, the upgrading program data of the MCU in the vehicle-mounted terminal is firstly sent to the SOC in the vehicle-mounted terminal, and then the upgrading program data is sent to the MCU through the inter-core communication interface for program burning, so that the program burning of the MCU through the Ethernet is realized, the problem that the upgrading of the MCU bottom layer driving firmware cannot be realized through the mode of burning the MCU through the Ethernet due to the fact that the MCU does not have a network card equipment is solved, and the efficiency of MCU program burning is ensured.

Description

Program burning method and device, vehicle-mounted terminal and medium

Technical Field

The present application relates to the field of automotive technologies, and in particular, to a program burning method, an apparatus, a vehicle-mounted terminal, and a medium.

Background

The car machine is a terminal device installed on an automobile, generally called a car terminal, and can functionally implement information communication between a person and a car, between a car and the outside, and when a car machine System operated by the car terminal is greatly changed, a bottom layer driving firmware of a System On Chip (SOC) and a Micro Control Unit (MCU) is generally required to be upgraded.

At present, there are two general upgrading methods for the bottom layer drive firmware of the MCU, one is to transmit the upgrading program data to the MCU for program burning through a Controller Area Network (CAN) bus, and the other is to transmit the upgrading program data to the MCU for program burning through the ethernet. Compared with the mode of burning the MCU through the CAN bus, the burning rate of the MCU through the Ethernet is improved hundreds of times, but in practical application, part of the MCUs of the vehicle-mounted terminal do not have network card equipment, and upgrading of the MCU bottom layer driving firmware cannot be realized through the mode of burning the MCU through the Ethernet.

Disclosure of Invention

The embodiment of the application provides a program burning method, a program burning device, a vehicle-mounted terminal and a medium, which are used for solving the problem that in the prior art, as an MCU does not have a network card device, the upgrading of MCU bottom layer drive firmware cannot be realized in an Ethernet burning MCU mode.

The technical scheme provided by the embodiment of the application is as follows:

on one hand, the embodiment of the application provides a program burning method applied to an SOC in a vehicle-mounted terminal, which comprises the following steps:

receiving a diagnosis upgrading service request sent by diagnosis equipment;

based on the memory address range in the diagnosis upgrading service request, when the target upgrading object is determined to be a Micro Control Unit (MCU), verifying whether the MCU meets the upgrading condition, and returning an upgrading condition verification result to the diagnosis equipment;

and receiving upgrade program data sent by the diagnosis equipment when the MCU meets the upgrade condition based on the upgrade condition verification result, and sending the upgrade program data to the MCU through the inter-core communication interface for program burning.

On the other hand, the embodiment of the application provides a program burning method applied to an MCU in a vehicle-mounted terminal, which includes:

receiving upgrading program data sent by a system level chip SOC through an inter-core communication interface; the upgrading program data is that the SOC determines that a target upgrading object is an MCU based on a memory address range in a diagnosis upgrading service request sent by the diagnosis equipment, and after an upgrading condition verification result of the MCU is returned to the diagnosis equipment, the diagnosis equipment determines that the MCU meets the upgrading condition based on the upgrading condition verification result and sends the upgrading condition to the SOC;

and carrying out program burning based on the upgrading program data.

On the other hand, an embodiment of the present application provides a program burning method applied to a diagnostic device, including:

when a target upgrading object in the vehicle-mounted terminal is determined to be a Micro Control Unit (MCU), a diagnosis upgrading service request is sent to a System On Chip (SOC) in the vehicle-mounted terminal based on the memory address range of the MCU;

receiving an upgrading condition verification result of the MCU returned by the SOC; the upgrading condition verification result is returned after verifying whether the MCU meets the upgrading condition or not when the SOC determines that the target upgrading object is the MCU based on the memory address range in the diagnosis upgrading service request;

and when the MCU meets the upgrading condition based on the upgrading condition verification result, sending upgrading program data of the MCU to the SOC so that the SOC sends the upgrading program data to the MCU through the inter-core communication interface for program burning.

On the other hand, an embodiment of the present application provides a program burning device applied to an SOC in a vehicle-mounted terminal, including:

the request receiving unit is used for receiving a diagnosis upgrading service request sent by the diagnosis equipment;

the upgrading verification unit is used for verifying whether the MCU meets the upgrading condition or not and returning an upgrading condition verification result to the diagnosis equipment when the target upgrading object is determined to be the MCU based on the memory address range in the diagnosis upgrading service request;

the data receiving unit is used for receiving upgrading program data sent by the diagnosis equipment when the MCU meets the upgrading conditions according to the upgrading condition verification result;

and the data forwarding unit is used for sending the upgrading program data to the MCU for program burning through the inter-core communication interface.

On the other hand, the embodiment of the present application provides a program burning device for an MCU in a vehicle-mounted terminal, including:

the system comprises a data receiving unit, a data processing unit and a data processing unit, wherein the data receiving unit is used for receiving upgrading program data sent by a system-on-chip SOC through an inter-core communication interface; the upgrading program data is that the SOC determines that a target upgrading object is an MCU based on a memory address range in a diagnosis upgrading service request sent by the diagnosis equipment, and after an upgrading condition verification result of the MCU is returned to the diagnosis equipment, the diagnosis equipment determines that the MCU meets the upgrading condition based on the upgrading condition verification result and sends the upgrading condition to the SOC;

and the program burning unit is used for burning the program based on the upgrading program data.

On the other hand, an embodiment of the present application provides a program burning apparatus applied to a diagnostic device, including:

the system comprises a request sending unit, a system level chip SOC and a micro control unit MCU, wherein the request sending unit is used for sending a diagnosis upgrading service request to the system level chip SOC in the vehicle-mounted terminal based on the memory address range of the MCU when determining that a target upgrading object in the vehicle-mounted terminal is the MCU;

the verification receiving unit is used for receiving the upgrading condition verification result of the MCU returned by the SOC; the upgrading condition verification result is returned after verifying whether the MCU meets the upgrading condition or not when the SOC determines that the target upgrading object is the MCU based on the memory address range in the diagnosis upgrading service request;

and the data transmitting unit is used for transmitting the upgrading program data of the MCU to the SOC when the MCU meets the upgrading condition based on the upgrading condition verification result so that the SOC transmits the upgrading program data to the MCU through the inter-core communication interface for program burning.

On the other hand, an embodiment of the present application provides a vehicle-mounted terminal, including: the program burning method applied to the SOC provided by the embodiment of the application is realized when the SOC executes the first computer program, and the program burning method applied to the MCU provided by the embodiment of the application is realized when the MCU executes the second computer program.

In another aspect, an embodiment of the present application provides a diagnostic apparatus, including: the device comprises a memory, a processor and a computer program which is stored on the memory and can run on the processor, wherein when the processor executes the computer program, the program burning method applied to the diagnostic device provided by the embodiment of the application is realized.

On the other hand, the embodiment of the present application further provides a computer-readable storage medium, where computer instructions are stored, and when the computer instructions are executed, the method for programming the SOC applied to the vehicle-mounted terminal provided by the embodiment of the present application is implemented; or the program burning method applied to the MCU in the vehicle-mounted terminal provided by the embodiment of the application is realized; or the program burning method applied to the diagnostic equipment provided by the embodiment of the application is realized.

The beneficial effects of the embodiment of the application are as follows:

in the embodiment of the application, Ethernet communication between SOC among diagnostic equipment and the vehicle mounted terminal is utilized, the upgrading program data of MCU among the vehicle mounted terminal is firstly sent to SOC among the vehicle mounted terminal, SOC among the vehicle mounted terminal sends the upgrading program data of MCU to MCU through the inter-core communication interface for program burning, thereby realizing program burning to MCU through Ethernet, and further solving the problem that MCU bottom layer drive firmware upgrading can not be realized through the mode of burning MCU through Ethernet because MCU does not possess network card equipment, and the efficiency of MCU program burning is guaranteed.

Additional features and advantages of the application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the application. The objectives and other advantages of the application may be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:

FIG. 1 is a block diagram of a program burning system according to an embodiment of the present invention;

FIG. 2 is a schematic view illustrating an interaction flow of a program burning method according to an embodiment of the present application;

FIG. 3 is a schematic diagram illustrating a specific interaction flow of a program burning method according to an embodiment of the present application;

fig. 4 is a functional structure diagram of a program burning device applied to an SOC of a vehicle-mounted terminal in the embodiment of the present application;

fig. 5 is a functional structure diagram of a program burning device applied to an MCU in a vehicle-mounted terminal in the embodiment of the present application;

FIG. 6 is a functional block diagram of a program recording device applied to a diagnostic apparatus according to an embodiment of the present disclosure;

fig. 7 is a schematic diagram of a hardware structure of a vehicle-mounted terminal in the embodiment of the present application;

fig. 8 is a hardware configuration diagram of the diagnostic apparatus in the embodiment of the present application.

Detailed Description

In order to make the purpose, technical solution and advantages of the present application more clearly and clearly understood, the technical solution in the embodiments of the present application will be described below in detail and completely with reference to the accompanying drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

To facilitate a better understanding of the present application by those skilled in the art, a brief description of the technical terms involved in the present application will be given below.

1. The vehicle-mounted terminal can be installed on an automobile, has the functions of positioning, communication, driving recording, telephone calling, voice broadcasting, audio and video playing, security alarm, remote safe oil cut-off, power-off safety protection and the like, is reserved with a plurality of RS-232 interfaces and RS485 interfaces, and can be externally connected with front-end equipment such as a price calculator, a camera, a microphone, an earphone and the like.

2. The diagnostic equipment is equipment capable of performing operations such as performance detection, fault diagnosis and vehicle machine system upgrading on the automobile. In the present application, the diagnostic device may be, but is not limited to, a diagnostic instrument, a computer, or the like.

3. The Inter-core communication Interface is an Interface capable of implementing information communication between the SOC and the MCU in the vehicle-mounted terminal, and in the present application, the Inter-core communication Interface may be, but is not limited to, a Serial Peripheral Interface (SPI) Interface, an Integrated Circuit bus (IIC) Interface, or the like.

It should be noted that, in the present application, the terms "first", "second", and the like are used for distinguishing similar objects, and are not necessarily used for describing a specific order or sequence. It is to be understood that such terms are interchangeable under appropriate circumstances such that the embodiments described herein are capable of operation in sequences other than those illustrated or otherwise described herein.

After introducing the technical terms related to the present application, the following briefly introduces the application scenarios and design ideas of the embodiments of the present application.

At present, in order to improve the efficiency of program burning of the MCU of the vehicle-mounted terminal, the ethernet is generally used for program burning of the MCU, but in practical application, part of the MCUs of the vehicle-mounted terminal do not have a network card device and cannot be programmed through the ethernet, thereby causing the failure of upgrading the MCU bottom layer driver firmware. For this reason, in the embodiment of the present application, referring to fig. 1, SOC111 in vehicle-mounted terminal 110 supports two protocols, namely, Diagnostic over Internet Protocol (DoIP) and Unified Diagnostic Service (UDS), and may establish a communication connection with Diagnostic device 120 through ethernet, and SOC111 in vehicle-mounted terminal 110 may also perform information communication with MCU112 through an inter-core communication interface. In practical application, when the diagnosis device 120 determines that a target upgrading object in the vehicle-mounted terminal 110 is the MCU112, the upgrading program data of the MCU112 is sent to the SOC111 in the vehicle-mounted terminal 110 through ethernet communication with the SOC111 in the vehicle-mounted terminal 110, and the SOC111 in the vehicle-mounted terminal 110 sends the upgrading program data of the MCU112 to the MCU112 through the inter-core communication interface for program burning, so that program burning of the MCU112 through the ethernet is realized, thereby solving a problem that upgrading of a bottom-layer driving firmware of the MCU112 cannot be realized through a method of burning the MCU112 by using the ethernet since the MCU112 does not have a network card device, and ensuring the efficiency of program burning of the MCU 112.

After introducing the application scenario and the design concept of the embodiment of the present application, the following describes in detail the technical solution provided by the embodiment of the present application.

An embodiment of the present application provides a program burning method, and referring to fig. 2, an interaction flow of the program burning method provided in the embodiment of the present application is as follows:

step 201: when the diagnosis device 120 determines that the target upgrade object in the vehicle-mounted terminal 110 is the MCU112, it sends a diagnosis upgrade service request to the SOC111 in the vehicle-mounted terminal 110 based on the memory address range of the MCU 112.

In practical application, the memory address ranges of the SOC111 and the MCU112 in the vehicle-mounted terminal 110 are different, and the SOC111 and the MCU112 can be identified through the memory address ranges of the SOC111 and the MCU112, based on which, when the diagnosis device 120 determines that the target upgrade object in the vehicle-mounted terminal 110 is the MCU112, the diagnosis device can send a diagnosis upgrade service request to the SOC111 in the vehicle-mounted terminal 110 based on the memory address range of the MCU112, so that the SOC111 in the vehicle-mounted terminal 110 can determine that the MCU112 is the target upgrade object according to the memory address range in the diagnosis upgrade service request.

In this embodiment, when the diagnostic device 120 determines that the target upgrade object in the vehicle-mounted terminal 110 is the SOC111, the diagnostic device may also send a diagnostic upgrade service request to the SOC111 in the vehicle-mounted terminal 110 based on the memory address range of the SOC111, so that the SOC111 in the vehicle-mounted terminal 110 may determine that the SOC111 itself is the target upgrade object according to the memory address range in the diagnostic upgrade service request.

Step 202: after receiving the diagnosis upgrade service request sent by the diagnosis device 120, the SOC111 in the vehicle-mounted terminal 110 verifies whether the MCU112 satisfies the upgrade condition when determining that the target upgrade object is the MCU112 based on the memory address range in the diagnosis upgrade service request.

In practical application, after the SOC111 in the vehicle-mounted terminal 110 determines that the target upgrade object is the MCU112 based on the memory address range in the diagnosis upgrade service request, when verifying whether the MCU112 meets the upgrade condition, the following method may be adopted, but is not limited to:

first, SOC111 in-vehicle terminal 110 may send a memory state query request to MCU112 through an inter-core communication interface.

Then, after receiving the memory state query request sent by SOC111 through the inter-core communication interface, MCU112 in vehicle-mounted terminal 110 may obtain the memory state information based on the memory state query request, and return the memory state information to SOC111 through the inter-core communication interface.

Finally, after receiving the memory state information returned by the MCU112 through the inter-core communication interface, the SOC111 in the vehicle-mounted terminal 110 may determine whether the memory of the MCU112 is in an idle state and not less than the memory occupied by the upgrade program data based on the memory state information; if so, it may be determined that the MCU112 satisfies the upgrade condition; if not, it may be determined that MCU112 does not satisfy the upgrade condition.

In this embodiment of the present application, when the SOC111 in the vehicle-mounted terminal 110 determines that the target upgrade object is the SOC111 based on the memory address range in the diagnosis upgrade service request, it may also be verified whether the SOC111 satisfies the upgrade condition, specifically, the following manner may be adopted, but is not limited to:

first, SOC111 in-vehicle terminal 110 acquires its own memory state information.

Then, the SOC111 in the vehicle-mounted terminal 110 determines whether the memory of the SOC is in an idle state and is not less than the memory occupied by the upgrade program data based on the memory state information of the SOC; if yes, determining that the self meets the upgrading condition; if not, the user can be determined not to meet the upgrading condition.

Step 203: the SOC111 in the in-vehicle terminal 110 returns the upgrade condition verification result of the MCU112 to the diagnosis device 120.

In this embodiment, when the SOC111 in the vehicle-mounted terminal 110 determines that the target upgrade object is itself, after verifying whether itself meets the upgrade condition, it may also return the verification result of its upgrade condition to the diagnostic device 120.

Step 204: after receiving the upgrade condition verification result of the MCU112 returned by the SOC111 in the in-vehicle terminal 110, the diagnostic device 120 transmits the upgrade program data of the MCU112 to the SOC111 in the in-vehicle terminal 110 when determining that the MCU112 satisfies the upgrade condition based on the upgrade condition verification result.

In this embodiment of the application, when the diagnostic device 120 determines that the MCU112 does not satisfy the upgrade condition based on the upgrade condition verification result, the program burning process may be directly interrupted, the MCU112 upgrade failure is determined, and the prompt information representing the MCU112 upgrade failure is sent to the SOC111 in the vehicle-mounted terminal 110 for display.

It is worth mentioning that, in the embodiment of the present application, after the diagnostic device 120 determines that the MCU112 meets the upgrade condition based on the upgrade condition verification result, before the upgrade program data of the MCU112 is sent to the SOC111 in the vehicle-mounted terminal 110, the MCU112 in the vehicle-mounted terminal 110 may be further controlled to switch to the upgrade mode. Specifically, the following modes can be adopted, but not limited to:

first, the diagnosis device 120 transmits an upgrade mode switching request to the SOC111 in the in-vehicle terminal 110.

Next, when receiving the upgrade mode switching request sent by the diagnostic device 120, the SOC111 in the in-vehicle terminal 110 forwards the upgrade mode switching request to the MCU112 through the inter-core communication interface.

Then, when receiving the upgrade mode switching request forwarded by SOC111, MCU112 in-vehicle terminal 110 switches to the upgrade mode based on the upgrade mode switching request, and returns an upgrade mode switching response to SOC111 through the inter-core communication interface.

Again, when receiving the upgrade mode switching response transmitted by the MCU112, the SOC111 in the in-vehicle terminal 110 forwards the upgrade mode switching response to the diagnostic apparatus 120.

Finally, after receiving the upgrade mode switching response forwarded by SOC111 in-vehicle terminal 110, diagnostic device 120 determines that the upgrade mode of MCU112 is switched based on the upgrade mode switching response.

Further, in order to improve the safety of program burning, the diagnostic device 120 may perform safety access verification before sending the upgrade program data of the MCU112 to the SOC111 in the vehicle-mounted terminal 110 after determining that the upgrade mode of the MCU112 is switched. Specifically, the following modes can be adopted, but not limited to:

first, the diagnosis device 120 transmits a security access request to the SOC111 in the in-vehicle terminal 110.

Next, when receiving the security access request sent by the diagnostic device 120, the SOC111 in the in-vehicle terminal 110 performs security verification on the diagnostic device 120 based on the negotiated security access algorithm.

In implementation, the SOC111 in the in-vehicle terminal 110 may generate a random number and send the random number to the diagnostic device 120; when the diagnostic device 120 receives the random number sent by the SOC111 in the vehicle-mounted terminal 110, the random number is calculated by using a locally stored security access algorithm negotiated with the SOC111 in the vehicle-mounted terminal 110, and the first verification code is obtained and then returned to the SOC111 in the vehicle-mounted terminal 110; after receiving the first verification code returned by the diagnostic device 120, the SOC111 in the vehicle-mounted terminal 110 calculates the generated random number by using a locally stored security access algorithm negotiated with the diagnostic device 120 to obtain a second verification code, and determines that the security verification of the diagnostic device 120 is passed when detecting that the first verification code is the same as the second verification code, otherwise, determines that the security verification of the diagnostic device 120 is not passed.

Then, the SOC111 in the in-vehicle terminal 110 returns the safety verification result of the diagnostic device 120 to the diagnostic device 120.

Finally, the diagnosis device 120 receives the security verification result returned by the SOC111 in the in-vehicle terminal 110, and determines whether the security verification is passed based on the security verification result.

In this embodiment, after the diagnostic device 120 determines that the security verification passes based on the security verification result, before the upgrade program data of the MCU112 is sent to the SOC111 in the vehicle-mounted terminal 110, the MCU112 in the vehicle-mounted terminal 110 may be controlled to erase and write the memory. Specifically, the following modes can be adopted, but not limited to:

first, the diagnostic device 120 transmits a memory erasure request to the SOC111 in the in-vehicle terminal 110.

Next, after receiving the memory erasure request sent by the diagnostic device 120, the SOC111 in the vehicle-mounted terminal 110 forwards the memory erasure request to the MCU112 through the inter-core communication interface.

Then, when receiving the memory erasure request forwarded by SOC111, MCU112 in-vehicle terminal 110 erases the memory based on the memory erasure request, and returns a memory erasure response to SOC111 through the inter-core communication interface.

Then, after receiving the memory erasure response returned by the MCU112, the SOC111 in the in-vehicle terminal 110 forwards the memory erasure response to the diagnostic device 120.

Finally, after the diagnostic device 120 receives the memory erasure response forwarded by the SOC111 in the in-vehicle terminal 110, it determines that the memory erasure of the MCU12 is completed based on the memory erasure response.

Further, after the diagnostic device 120 determines that the memory erasure of the MCU12 is completed based on the memory erasure response, the upgrade program data of the MCU12 may be sent to the SOC111 in the in-vehicle terminal 110.

It should be noted that, in the embodiment of the present application, after the diagnostic device 120 determines that the target upgrade object in the vehicle-mounted terminal 110 is the SOC111 and sends the diagnostic upgrade service request to the SOC111 in the vehicle-mounted terminal 110 based on the memory address range of the SOC111, when an upgrade condition verification result of the SOC111 returned by the SOC111 in the vehicle-mounted terminal 110 is received, it may be determined whether the SOC111 satisfies the upgrade condition based on the upgrade condition verification result.

Further, when the diagnostic device 120 determines that the SOC111 does not meet the upgrade condition based on the upgrade condition verification result, the program burning process may be directly interrupted, the SOC111 is determined to be failed to be upgraded, and prompt information representing the SOC111 that is failed to be upgraded is sent to the SOC111 in the vehicle-mounted terminal 110 for display. Of course, when the diagnostic device 120 determines that the SOC111 satisfies the upgrade condition based on the verification result of the upgrade condition, the diagnostic device may continue to control the SOC111 to switch to the upgrade mode, specifically, but not limited to, the following manners may be adopted:

Then, when receiving the upgrade mode switching request transmitted by the diagnostic device 120, the SOC111 in the in-vehicle terminal 110 switches to the upgrade mode based on the upgrade mode switching request, and returns an upgrade mode switching response to the diagnostic device 120.

Finally, when the diagnosis device 120 receives the upgrade mode switching response transmitted by the SOC111 in the in-vehicle terminal 110, it determines that the upgrade mode switching of the SOC111 is completed based on the upgrade mode switching response.

Further, after the diagnostic device 120 determines that the SOC111 upgrade mode is switched, security access verification may also be performed, where a specific verification method is the same as the above-described method, and is not described herein again.

Further, the diagnostic device 120 may instruct the SOC111 in the in-vehicle terminal 110 to erase and write the memory when determining that the security verification passes. Specifically, the following modes can be adopted, but not limited to:

Then, after receiving the memory erasure request sent by the diagnostic device 120, the SOC111 in the in-vehicle terminal 110 erases the memory based on the memory erasure request, and sends a memory erasure response to the diagnostic device 120.

Finally, when the diagnostic device 120 receives the memory erasure response sent by the SOC111 in the in-vehicle terminal 110, it determines that the memory erasure of the SOC111 is completed based on the memory erasure response.

Further, the diagnostic device 120 may send the upgrade program data of the SOC111 to the SOC111 in the in-vehicle terminal 110 after determining that the memory erasure of the SOC111 is completed based on the memory erasure response.

Step 205: after receiving the upgrade program data sent by the diagnostic device 120, the SOC111 in the in-vehicle terminal 110 sends the upgrade program data to the MCU112 through the inter-core communication interface.

In practical application, in order to ensure smooth programming, after receiving the upgrade program data sent by the diagnostic device 120, the SOC111 in the vehicle-mounted terminal 110 may further perform integrity check and compatibility detection on the upgrade program data, determine that the integrity check of the upgrade program data passes based on the integrity check result of the upgrade program data, and send the upgrade program data to the MCU112 through the inter-core communication interface when determining that the compatibility check of the upgrade program data passes based on the compatibility check result of the upgrade program data.

It is worth mentioning that, if the target upgrade object is the SOC111 in the vehicle-mounted terminal 110, after the SOC111 in the vehicle-mounted terminal 110 receives the upgrade program data sent by the diagnostic device 120, integrity check and compatibility detection may be performed on the upgrade program data, and when it is determined that both the integrity check and the compatibility detection of the upgrade program data pass, program burning is performed based on the upgrade program data.

Further, after the SOC111 in the vehicle-mounted terminal performs program burning based on the upgrade program data, a diagnosis upgrade service response may be returned to the diagnostic device 120, and the vehicle-mounted terminal may be restarted under the control of the diagnostic device 120. Specifically, the following modes can be adopted, but not limited to:

first, the SOC111 in the in-vehicle terminal 110 returns a diagnosis upgrade service response to the diagnosis device 120.

Next, when the diagnosis device 120 receives the diagnosis upgrade service response sent by the SOC111 in the vehicle-mounted terminal 110, after it is determined that the burning of the program of the SOC111 is completed based on the diagnosis upgrade service response, the diagnosis device sends an SOC restart request to the SOC 111.

Then, after receiving the restart SOC request sent by the diagnostic device 120, the SOC111 in the in-vehicle terminal 110 restarts based on the restart SOC request, and returns a restart SOC response to the diagnostic device 120.

Finally, after the diagnostic device 120 receives the restart SOC response sent by the SOC111 in the in-vehicle terminal 110, when it is determined that the restart of the SOC111 is completed based on the restart SOC response, it is determined that the SOC11 completes the upgrade.

Step 206: after receiving the upgrade program data sent by the SOC111 through the inter-core communication interface, the MCU112 in the vehicle-mounted terminal 110 performs program burning based on the upgrade program data.

Further, after the MCU112 in the vehicle-mounted terminal 110 performs program burning based on the upgrade program data, a diagnosis upgrade service response may be returned to the diagnosis device 120, and the vehicle-mounted terminal may be restarted under the control of the diagnosis device 120. Specifically, the following modes can be adopted, but not limited to:

first, the MCU112 in the in-vehicle terminal 110 returns a diagnosis upgrade service response to the SOC111 in the in-vehicle terminal 110 through the inter-core communication interface.

Next, when receiving the diagnosis upgrade service response returned by the MCU112, the SOC111 in the in-vehicle terminal 110 forwards the diagnosis upgrade service response to the diagnosis device 120.

Then, after receiving the diagnosis upgrade service response forwarded by the SOC111 in the vehicle-mounted terminal 110, the diagnosis device 120 sends an MCU restart request to the SOC111 in the vehicle-mounted terminal 110 when it is determined that the MCU112 program is completely burned based on the diagnosis upgrade service response.

Thirdly, after receiving the MCU restart request sent by the diagnostic device 120, the SOC111 in the vehicle-mounted terminal 110 forwards the MCU restart request to the MCU112 through the inter-core communication interface.

Subsequently, after receiving the MCU restart request forwarded by the SOC111 through the inter-core communication interface, the MCU112 in the vehicle-mounted terminal 110 restarts based on the MCU restart request, and returns an MCU restart response to the SOC111 through the inter-core communication interface.

Subsequently, after receiving the MCU restart response sent by the MCU112, the SOC111 in the in-vehicle terminal 110 forwards the MCU restart response to the diagnostic device 120.

Finally, after receiving the MCU restart response forwarded by the SOC111 in the vehicle-mounted terminal 110, the diagnostic device 120 determines that the MCU112 has completed upgrading when determining that the MCU112 has completed restarting based on the MCU restart response.

The program burning method provided in the embodiment of the present application is further described in detail below with reference to fig. 3, which uses "the diagnostic device 120 performs program burning on the MCU112 in the vehicle-mounted terminal 110" as a specific application scenario, and the specific process of the program burning method provided in the embodiment of the present application is as follows:

step 301: when the diagnosis device 120 determines that the target upgrade object in the vehicle-mounted terminal 110 is the MCU112, it sends a diagnosis upgrade service request to the SOC111 in the vehicle-mounted terminal 110 based on the memory address range of the MCU 112.

Step 302: after receiving the diagnosis upgrade service request sent by the diagnosis device 120, the SOC111 in the vehicle-mounted terminal 110 sends a memory state query request to the MCU112 through the inter-core communication interface when determining that the target upgrade object is the MCU112 based on the memory address range in the diagnosis upgrade service request.

Step 303: after receiving the memory state query request sent by SOC111 through the inter-core communication interface, MCU112 in vehicle-mounted terminal 110 obtains the memory state information based on the memory state query request.

Step 304: the MCU112 in the in-vehicle terminal 110 returns the memory state information to the SOC111 through the inter-core communication interface.

Step 305: after receiving the memory state information returned by the MCU112 through the inter-core communication interface, the SOC111 in the vehicle-mounted terminal 110 determines that the MCU112 satisfies the upgrade condition when detecting that the memory of the MCU112 is in an idle state and not less than the memory occupied by the upgrade program data based on the memory state information.

Step 306: the SOC111 in the in-vehicle terminal 110 returns the upgrade condition verification result of the MCU112 to the diagnosis device 120.

Step 307: after receiving the upgrade condition verification result of the MCU112 returned by the SOC111 in the in-vehicle terminal 110, the diagnostic device 120 sends an upgrade mode switching request to the SOC111 in the in-vehicle terminal 110 when determining that the MCU112 satisfies the upgrade condition based on the upgrade condition verification result.

Step 308: when receiving the upgrade mode switching request sent by the diagnostic device 120, the SOC111 in the in-vehicle terminal 110 forwards the upgrade mode switching request to the MCU112 through the inter-core communication interface.

Step 309: when receiving the upgrade mode switching request forwarded by SOC111, MCU112 in-vehicle terminal 110 switches to the upgrade mode based on the upgrade mode switching request.

Step 310: the MCU112 in the in-vehicle terminal 110 returns an upgrade mode switching response to the SOC111 through the inter-core communication interface.

Step 311: when receiving the upgrade mode switching response transmitted by the MCU112, the SOC111 in the in-vehicle terminal 110 forwards the upgrade mode switching response to the diagnostic apparatus 120.

Step 312: after receiving the upgrade mode switching response forwarded by SOC111 in-vehicle terminal 110, diagnostic device 120 sends a security access request to SOC111 in-vehicle terminal 110 when determining that MCU112 has completed switching of the upgrade mode based on the upgrade mode switching response.

Step 313: the SOC111 in the in-vehicle terminal 110 generates a random number when receiving the security access request transmitted from the diagnostic device 120.

Step 314: the SOC111 in the in-vehicle terminal 110 transmits the random number to the diagnostic apparatus 120.

Step 315: when the diagnostic device 120 receives the random number sent by the SOC111 in the vehicle-mounted terminal 110, the random number is calculated by using a locally stored security access algorithm negotiated with the SOC111 in the vehicle-mounted terminal 110, so as to obtain a first verification code.

Step 316: the diagnosis device 120 returns the first verification code to the SOC111 in the in-vehicle terminal 110.

Step 317: after receiving the first verification code returned by the diagnostic device 120, the SOC111 in the in-vehicle terminal 110 calculates the generated random number by using a locally stored security access algorithm negotiated with the diagnostic device 120 to obtain a second verification code, and determines that the security verification of the diagnostic device 120 is passed when detecting that the first verification code is the same as the second verification code.

Step 318: the SOC111 in the in-vehicle terminal 110 returns the security verification result of the diagnostic device 120 to the diagnostic device 120.

Step 319: after receiving the security verification result returned by the SOC111 in the in-vehicle terminal 110, the diagnostic device 120 sends a memory erasing request to the SOC111 in the in-vehicle terminal 110 when determining that the security verification passes based on the security verification result.

Step 320: after receiving the memory erasure request sent by the diagnostic device 120, the SOC111 in the vehicle-mounted terminal 110 forwards the memory erasure request to the MCU112 through the inter-core communication interface.

Step 321: when receiving the memory erasure request forwarded by SOC111, MCU112 in-vehicle terminal 110 erases the memory based on the memory erasure request.

Step 322: the MCU112 in the in-vehicle terminal 110 returns a memory erase-write response to the SOC111 through the inter-core communication interface.

Step 323: after receiving the memory erasure response returned by the MCU112, the in-vehicle terminal 110 forwards the memory erasure response to the diagnostic device 120.

Step 324: after receiving the memory erasure response forwarded by the SOC111 in the in-vehicle terminal 110, the diagnostic device 120 sends the upgrade program data of the MCU12 to the SOC111 in the in-vehicle terminal 110 when determining that the memory erasure of the MCU12 is completed based on the memory erasure response.

Step 325: after receiving the upgrade program data of the MCU12 sent by the diagnostic device 120, the SOC111 in the in-vehicle terminal 110 performs integrity check and compatibility detection on the upgrade program data.

Step 326: the SOC111 in the vehicle-mounted terminal 110 determines that the integrity check of the upgrade program data passes based on the integrity check result of the upgrade program data, and transmits the upgrade program data to the MCU112 through the inter-core communication interface when it is determined that the compatibility check of the upgrade program data passes based on the compatibility check result of the upgrade program data.

Step 327: after receiving the upgrade program data sent by the SOC111 through the inter-core communication interface, the MCU112 in the vehicle-mounted terminal 110 performs program burning based on the upgrade program data.

Step 328: the MCU112 in the in-vehicle terminal 110 returns a diagnosis upgrade service response to the SOC111 in the in-vehicle terminal 110 through the inter-core communication interface.

Step 329: when receiving the diagnosis upgrade service response returned by the MCU112, the SOC111 in the in-vehicle terminal 110 forwards the diagnosis upgrade service response to the diagnosis device 120.

Step 330: after receiving the diagnosis upgrade service response forwarded by the SOC111 in the vehicle-mounted terminal 110, the diagnosis device 120 sends an MCU restart request to the SOC111 in the vehicle-mounted terminal 110 when it is determined that the MCU112 program is completely burned based on the diagnosis upgrade service response.

Step 331: after receiving the MCU restart request sent by the diagnostic device 120, the SOC111 in the vehicle-mounted terminal 110 forwards the MCU restart request to the MCU112 through the inter-core communication interface.

Step 332: after receiving the MCU restart request forwarded by the SOC111 through the inter-core communication interface, the MCU112 in the vehicle-mounted terminal 110 restarts based on the MCU restart request.

Step 333: the MCU112 in the in-vehicle terminal 110 returns a restart MCU response to the SOC111 through the inter-core communication interface.

Step 334: after receiving the restart MCU response sent by the MCU112, the SOC111 in the vehicle-mounted terminal 110 forwards the restart MCU response to the diagnostic device 120.

Step 335: after the diagnostic device 120 receives the MCU restart response forwarded by the SOC111 in the vehicle-mounted terminal 110, when it is determined that the MCU112 is completely restarted based on the MCU restart response, it is determined that the MCU112 completes the upgrade.

Based on the foregoing embodiments, an embodiment of the present application provides a program burning device applied to SOC111 in vehicle-mounted terminal 110, and referring to fig. 4, a program burning device 400 applied to SOC111 in vehicle-mounted terminal 110 provided in an embodiment of the present application at least includes:

a request receiving unit 401, configured to receive a diagnosis upgrade service request sent by the diagnosis device 120;

an upgrade verification unit 402, configured to verify whether the MCU112 meets an upgrade condition when determining that the target upgrade object is the MCU112 based on the memory address range in the diagnostic upgrade service request, and return an upgrade condition verification result to the diagnostic device 120;

a data receiving unit 403, configured to receive upgrade program data sent by the diagnostic device 120 when determining that the MCU112 meets the upgrade condition based on the upgrade condition verification result;

and a data forwarding unit 404, configured to send the upgrade program data to the MCU112 through the inter-core communication interface for program burning.

In a possible implementation manner, when verifying whether the MCU112 satisfies the upgrade condition, the upgrade verification unit 402 is specifically configured to:

sending a memory state query request to the MCU112 through the inter-core communication interface;

receiving memory state information returned by the MCU112 through the inter-core communication interface after acquiring the memory state information based on the memory state query request;

based on the memory state information, judging whether the memory of the MCU112 is in an idle state and is not less than the memory occupied by the upgrading program data;

if yes, determining that the MCU112 meets the upgrade condition;

if not, determining that the MCU112 does not meet the upgrade condition.

In a possible implementation manner, the program burning apparatus 400 applied to the SOC111 in the vehicle-mounted terminal 110 provided in the embodiment of the present application further includes:

a security verification unit 405, configured to receive a security access request sent by the diagnostic device 120; based on the negotiated security access algorithm, the security verification is performed on the diagnostic device 120, and the security verification result of the diagnostic device 120 is returned to the diagnostic device 120.

a memory erasing unit 406, configured to receive a memory erasing request sent by the diagnostic device 120; forwarding the memory erasing request to the MCU112 through the inter-core communication interface; and receiving a memory erasure response returned by the MCU112 through the inter-core communication interface after erasing the memory based on the memory erasure request, and forwarding the memory erasure response to the diagnostic device 120.

a data detection unit 407, configured to perform integrity check and compatibility detection on the upgrade program data; and determining that the integrity of the upgrade program data passes verification based on the integrity verification result of the upgrade program data, and determining that the compatibility of the upgrade program data passes verification based on the compatibility verification result of the upgrade program data.

a mode switching unit 408, configured to receive an upgrade mode switching request sent by the diagnostic device 120; forwarding the upgrade mode switch request to MCU112 through an inter-core communication interface; receiving an upgrade mode switching response returned by the MCU112 through the inter-core communication interface after switching to the upgrade mode based on the upgrade mode switching request, and forwarding the upgrade mode switching response to the diagnostic device 120.

the restarting unit 409 is configured to receive a diagnosis upgrade service response returned by the MCU112 through the inter-core communication interface after program burning is performed based on the upgrade program data, and forward the diagnosis upgrade service response to the diagnostic device 120; receiving a request for restarting the MCU112, which is sent by the diagnostic equipment 120 after determining that the burning of the MCU112 program is finished based on the diagnostic upgrade service response, and forwarding the request for restarting the MCU112 to the MCU112 through an inter-core communication interface; and receiving a restart MCU112 response returned by the MCU112 through the inter-core communication interface after the restart is requested by the MCU112 based on the restart MCU112, and forwarding the restart MCU112 response to the diagnostic device 120.

Based on the foregoing embodiment, an embodiment of the present application further provides a program burning device applied to the MCU112 in the vehicle-mounted terminal 110, and referring to fig. 5, the program burning device 500 applied to the MCU112 in the vehicle-mounted terminal 110 provided in the embodiment of the present application at least includes:

a data receiving unit 501, configured to receive upgrade program data sent by the SOC111 through an inter-core communication interface; the upgrading program data is that the SOC111 determines that a target upgrading object is the MCU112 based on a memory address range in a diagnosis upgrading service request sent by the diagnosis device 120, and after an upgrading condition verification result of the MCU112 is returned to the diagnosis device 120, the diagnosis device 120 determines that the MCU112 meets an upgrading condition based on the upgrading condition verification result and sends the upgrading condition to the SOC 111;

a program burning unit 502, configured to perform program burning based on the upgrade program data.

In a possible implementation manner, the program burning apparatus 500 applied to the MCU112 in the vehicle-mounted terminal 110 provided in this embodiment of the present application further includes:

the query execution unit 503 is configured to receive a memory state query request sent by the SOC111 through the inter-core communication interface; and acquiring the memory state information based on the memory state query request, and returning the memory state information to the SOC111 through the inter-core communication interface.

an erasure execution unit 504, configured to receive a memory erasure request forwarded by the SOC111 through an inter-core communication interface; and erasing and writing the memory based on the memory erasing and writing request, and returning a memory erasing and writing response to the SOC111 through the inter-core communication interface.

a switching execution unit 505, configured to receive an upgrade mode switching request forwarded by SOC111 through an inter-core communication interface; and switching to the upgrading mode based on the upgrading mode switching request, and returning an upgrading mode switching response to the SOC111 through the inter-core communication interface.

a restart execution unit 506, configured to send a diagnostic upgrade service response to the SOC111 through the inter-core communication interface; receiving a request for restarting the MCU112 forwarded by the SOC111 through an inter-core communication interface, wherein the request for restarting the MCU112 is that after the SOC111 forwards a diagnosis upgrade service response to the diagnostic equipment 120, the diagnostic equipment 120 determines that the MCU112 program is sent to the SOC111 when burning is finished based on the diagnosis upgrade service response; restarting is performed based on the restart MCU112 request, and a restart MCU112 response is returned to the SOC111 through the inter-core communication interface.

Based on the foregoing embodiments, an embodiment of the present application further provides a program burning apparatus applied to the diagnostic device 120, and referring to fig. 6, the program burning apparatus 600 applied to the diagnostic device 120 provided in the embodiment of the present application at least includes:

a request sending unit 601, configured to send a diagnosis and upgrade service request to a system on chip SOC111 in the vehicle-mounted terminal 110 based on a memory address range of the MCU112 when it is determined that a target upgrade object in the vehicle-mounted terminal 110 is the micro control unit MCU 112;

a verification receiving unit 602, configured to receive an upgrade condition verification result of the MCU112 returned by the SOC 111; if the SOC111 determines that the target upgrading object is the MCU112 based on the memory address range in the diagnosis upgrading service request, verifying whether the MCU112 meets the upgrading condition and then returning the verification result;

and the data sending unit 603 is configured to send the upgrade program data of the MCU112 to the SOC111 when it is determined that the MCU112 meets the upgrade condition based on the upgrade condition verification result, so that the SOC111 sends the upgrade program data to the MCU112 through the inter-core communication interface for program burning.

In a possible implementation manner, the program burning apparatus 600 applied to the diagnostic device 120 provided by the embodiment of the present application further includes:

a secure access unit 604 for sending a secure access request to the SOC 111; receiving a security verification result returned after the SOC111 performs security verification on the diagnostic device 120 based on the negotiated security access algorithm; and determining that the security verification is passed based on the security verification result.

an erasure control unit 605 for sending a memory erasure request to the SOC 111; receiving a memory erasing response forwarded by the SOC111, wherein the memory erasing response is that the SOC111 forwards a memory erasing request to the MCU112 through the inter-core communication interface, and the MCU112 returns to the SOC111 through the inter-core communication interface after erasing the memory based on the memory erasing request; the MCU112 is determined to have the memory erased based on the memory erase response.

a switching control unit 606 for sending an upgrade mode switching request to the SOC 111; receiving an upgrade mode switching response forwarded by the SOC111, wherein the upgrade mode switching response is that the SOC111 forwards an upgrade mode switching request to the MCU112 through an inter-core communication interface, and the MCU112 returns to the SOC111 through the inter-core communication interface after switching to an upgrade mode based on the upgrade mode switching request; it is determined that the MCU112 has completed the upgrade mode switching based on the upgrade mode switching response.

the restart control unit 607 is configured to receive a diagnosis upgrade service response forwarded by the SOC111, where the diagnosis upgrade service response is that the MCU112 returns to the SOC111 through the inter-core communication interface after performing program burning based on upgrade program data; after determining that the MCU112 program is completely burned based on the diagnosis upgrading service response, sending a request for restarting the MCU112 to the SOC 111; receiving a restart MCU112 response forwarded by the SOC111, wherein the restart MCU112 response is that the MCU112 returns to the SOC111 through an inter-core communication interface after being restarted based on a restart MCU112 request; MCU112 is determined to be restarted based on the restart MCU112 response.

It should be noted that the principle of solving the technical problem of the three program recording devices provided in the embodiment of the present application is similar to that of the program recording method provided in the embodiment of the present application, and therefore, the implementation of the three program recording devices provided in the embodiment of the present application can refer to the implementation of the program recording method provided in the embodiment of the present application, and repeated details are not repeated.

After the program burning method and apparatus provided in the embodiment of the present application are introduced, the vehicle-mounted terminal 110 and the diagnostic device 120 provided in the embodiment of the present application are briefly introduced next.

Referring to fig. 7, the vehicle-mounted terminal 110 provided in the embodiment of the present application at least includes an SOC111, an MCU112, and a memory 113, where the memory 113 stores a first computer program that can run on the SOC111 and a second computer program that can run on the MCU112, the SOC111 implements the program burning method applied to the SOC111 in the vehicle-mounted terminal 110 provided in the embodiment of the present application when executing the first computer program, and the MCU112 implements the program burning method applied to the MCU112 in the vehicle-mounted terminal 110 provided in the embodiment of the present application when executing the second computer program.

In the vehicle-mounted terminal 110 provided by the embodiment of the present application, the memory 113 may include one or more computer-readable storage media, and the computer-readable storage media may be non-transitory. The memory 113 may also include high speed random access memory as well as non-volatile memory, such as one or more magnetic disk storage devices, flash memory storage devices. In addition, the resources stored in the memory 113 may also include an operating system and data, and the storage may be a transient storage or a permanent storage, where the operating system may be Windows, Unix, Linux, and the like, and the data may include various data.

The vehicle-mounted terminal 110 provided by the embodiment of the application may further include a display screen 114, an input/output interface 115, a communication interface 116, a sensor 117, a power supply 118, a communication bus 119, and the like.

It should be noted that the vehicle-mounted terminal 110 shown in fig. 7 is only an example, and does not limit the vehicle-mounted terminal 110, and the vehicle-mounted terminal 110 may include more or less components than those shown in the drawings.

Referring to fig. 8, the diagnostic apparatus 120 provided in the embodiment of the present application at least includes: the processor 801 and the memory 802, the memory 802 stores a computer program that can be executed on the processor 801, and the processor 801 executes the computer program to implement the program burning method applied to the diagnostic apparatus 120 according to the embodiment of the present application.

The diagnostic device 800 provided by the embodiments of the present application may further include a bus 803 connecting the various components, including the processor 801 and the memory 802. Bus 803 represents one or more of any of several types of bus structures, including a memory bus, a peripheral bus, a local bus, and so forth.

The Memory 802 may include readable media in the form of volatile Memory, such as Random Access Memory (RAM) 8021 and/or cache Memory 8022, and may further include Read Only Memory (ROM) 8023.

Memory 802 may also include a program utility 8025 having a set (at least one) of program modules 8024, program modules 8024 including, but not limited to: an operating subsystem, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.

The diagnostic device 800 may also communicate with one or more external devices 804 (e.g., keyboard, remote control, etc.), with one or more devices that enable a user to interact with the diagnostic device 800 (e.g., cell phone, computer, etc.), and/or with any device that enables the diagnostic device 800 to communicate with one or more other diagnostic devices 800 (e.g., router, modem, etc.). Such communication may occur via an Input/Output (I/O) interface 805Line of. Also, the diagnostic device 800 may communicate with one or more networks (e.g., a Local Area Network (LAN), Wide Area Network (WAN), and/or a public Network, such as the internet) via the Network adapter 808. As shown in fig. 8, the network adapter 806 communicates with the other modules of the diagnostic device 800 via the bus 803. It should be understood that although not shown in fig. 8, other hardware and/or software modules may be used in conjunction with the diagnostic device 800, including but not limited to: microcode, device drivers, Redundant processors, external disk drive Arrays, disk array (RAID) subsystems, tape drives, and data backup storage subsystems, to name a few.

It should be noted that the diagnostic device 800 shown in fig. 8 is merely an example and is not meant to be limiting of the diagnostic device 800, and the diagnostic device 800 may include more or less components than those shown.

Next, a computer-readable storage medium provided by an embodiment of the present application will be described. The computer-readable storage medium provided by the embodiment of the present application stores computer instructions, and the computer instructions, when executed, implement the program burning method applied to the SOC111 in the vehicle-mounted terminal 110 provided by the embodiment of the present application; or implementing the program burning method applied to the MCU112 in the vehicle-mounted terminal 110 provided by the embodiment of the present application; or implement the program burning method applied to the diagnostic device 120 provided by the embodiment of the present application.

In addition, the program burning method applied to the SOC111 in the vehicle-mounted terminal 110 and the program burning method applied to the MCU112 in the vehicle-mounted terminal 110 provided in the embodiment of the present application may also be implemented as a program product including a program code for causing the vehicle-mounted terminal 110 to execute the program burning method applied to the SOC111 in the vehicle-mounted terminal 110 and the program burning method applied to the MCU112 in the vehicle-mounted terminal 110 provided in the embodiment of the present application when the program product can run on the vehicle-mounted terminal 110.

Of course, the program burning method applied to the diagnostic device 120 provided in the embodiment of the present application may also be implemented as a program product, where the program product includes program code, and when the program product can run on the diagnostic device 120, the program code is used to make the diagnostic device 120 execute the program burning method applied to the diagnostic device 120 provided in the embodiment of the present application.

The program product provided by the embodiments of the present application may be any combination of one or more readable media, where the readable media may be a readable signal medium or a readable storage medium, and the readable storage medium may be, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof, and in particular, more specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a RAM, a ROM, an Erasable Programmable Read-Only Memory (EPROM), an optical fiber, a portable Compact disk Read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

The program product provided by the embodiment of the application can adopt a CD-ROM and comprises program codes, and can run on a computing device. However, the program product provided by the embodiments of the present application is not limited thereto, and in the embodiments of the present application, the readable storage medium may be any tangible medium that can contain or store a program, which can be used by or in connection with an instruction execution system, apparatus, or device.

It should be noted that although several units or sub-units of the apparatus are mentioned in the above detailed description, such division is merely exemplary and not mandatory. Indeed, the features and functions of two or more units described above may be embodied in one unit, according to embodiments of the application. Conversely, the features and functions of one unit described above may be further divided into embodiments by a plurality of units.

Further, while the operations of the methods of the present application are depicted in the drawings in a particular order, this does not require or imply that these operations must be performed in this particular order, or that all of the illustrated operations must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions.

While the preferred embodiments of the present application have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all alterations and modifications as fall within the scope of the application.

It will be apparent to those skilled in the art that various changes and modifications may be made in the embodiments of the present application without departing from the spirit and scope of the embodiments of the present application. Thus, if such modifications and variations of the embodiments of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to encompass such modifications and variations.

Claims

1. A program burning method is characterized in that the program burning method is applied to a System On Chip (SOC) in a vehicle-mounted terminal, and comprises the following steps:

receiving a diagnosis upgrading service request sent by diagnosis equipment;

based on the memory address range in the diagnosis upgrading service request, when a target upgrading object is determined to be a Micro Control Unit (MCU), verifying whether the MCU meets an upgrading condition, and returning an upgrading condition verification result to the diagnosis equipment;

and receiving upgrade program data sent by the diagnosis equipment when the MCU meets the upgrade condition based on the upgrade condition verification result, and sending the upgrade program data to the MCU for program burning through an inter-core communication interface.

2. The program burning method of claim 1, wherein verifying whether the MCU meets the upgrade condition comprises:

sending a memory state query request to the MCU through the inter-core communication interface;

receiving the memory state information returned by the MCU through the inter-core communication interface after the MCU acquires the memory state information based on the memory state query request;

judging whether the memory of the MCU is in a non-working state and is not less than the memory occupied by the upgrading program data or not based on the memory state information;

if yes, determining that the MCU meets the upgrading condition;

if not, determining that the MCU does not meet the upgrading condition.

3. The program burning method of claim 1, wherein after returning the verification result of the upgrade condition to the diagnostic device, further comprising:

receiving a security access request sent by the diagnosis equipment;

and performing security verification on the diagnostic equipment based on the negotiated security access algorithm, and returning the security verification result of the diagnostic equipment to the diagnostic equipment.

4. The program burning method of claim 1, wherein after returning the verification result of the upgrade condition to the diagnostic device, further comprising:

receiving a memory erasing request sent by the diagnostic equipment;

forwarding the memory erasing request to the MCU through the inter-core communication interface;

and receiving a memory erasing response returned by the MCU through the inter-core communication interface after the MCU erases the memory based on the memory erasing request, and forwarding the memory erasing response to the diagnostic equipment.

5. The program burning method according to any one of claims 1 to 4, wherein before sending the upgrade program data to the MCU through an inter-core communication interface for program burning, the method further comprises:

carrying out integrity check and compatibility detection on the upgrading program data;

and determining that the integrity of the upgrade program data passes the verification based on the integrity verification result of the upgrade program data, and determining that the compatibility of the upgrade program data passes the verification based on the compatibility verification result of the upgrade program data.

6. The program burning method according to any one of claims 1 to 4, wherein before sending the upgrade program data to the MCU through an inter-core communication interface for program burning, the method further comprises:

receiving an upgrade mode switching request sent by the diagnosis equipment;

forwarding the upgrade mode switching request to the MCU through the inter-core communication interface;

and receiving an upgrade mode switching response returned by the MCU through the inter-core communication interface after the MCU is switched to an upgrade mode based on the upgrade mode switching request, and forwarding the upgrade mode switching response to the diagnostic equipment.

7. The program burning method according to any one of claims 1 to 4, wherein after sending the upgrade program data to the MCU through an inter-core communication interface for program burning, further comprising:

receiving a diagnosis upgrading service response returned by the MCU through the inter-core communication interface after the MCU carries out program burning based on the upgrading program data, and forwarding the diagnosis upgrading service response to the diagnosis equipment;

receiving a restart MCU request sent by the diagnosis equipment after the diagnosis upgrading service response determines that the MCU program is completely burnt, and forwarding the restart MCU request to the MCU through the inter-core communication interface;

and receiving a restart MCU response returned by the MCU through the inter-core communication interface after the MCU is restarted based on the restart MCU request, and forwarding the restart MCU response to the diagnostic equipment.

8. A program burning method is characterized in that a Micro Control Unit (MCU) applied to a vehicle-mounted terminal comprises the following steps:

receiving upgrading program data sent by a system level chip SOC through an inter-core communication interface; the upgrading program data is that the SOC determines that a target upgrading object is the MCU based on a memory address range in a diagnosis upgrading service request sent by diagnosis equipment, and after an upgrading condition verification result of the MCU is returned to the diagnosis equipment, the diagnosis equipment determines that the MCU meets the upgrading condition based on the upgrading condition verification result and sends the upgrading condition to the SOC;

and carrying out program burning based on the upgrading program data.

9. The program burning method of claim 8, wherein before receiving the upgrade program data sent by the SOC through the inter-core communication interface, the method further comprises:

receiving a memory state query request sent by the SOC through the inter-core communication interface;

and acquiring memory state information based on the memory state query request, and returning the memory state information to the SOC through the inter-core communication interface.

10. The program burning method of claim 8, wherein before receiving the upgrade program data sent by the SOC through the inter-core communication interface, the method further comprises:

receiving a memory erasing request forwarded by the SOC through the inter-core communication interface;

and erasing and writing the memory based on the memory erasing and writing request, and returning a memory erasing and writing response to the SOC through the inter-core communication interface.

11. The program burning method according to any one of claims 8 to 10, further comprising, before performing program burning based on the upgrade program data:

receiving an upgrading mode switching request forwarded by the SOC through the inter-core communication interface;

and switching to an upgrading mode based on the upgrading mode switching request, and returning an upgrading mode switching response to the SOC through the inter-core communication interface.

12. The program burning method according to any one of claims 8 to 10, further comprising, after the program burning based on the upgrade program data:

sending a diagnostic upgrade service response to the SOC through the inter-core communication interface;

receiving a restart MCU request forwarded by the SOC through the inter-core communication interface; the MCU restarting request is that after the SOC forwards the diagnosis upgrading service response to the diagnosis equipment, the diagnosis equipment determines that the MCU program is sent to the SOC after burning is finished based on the diagnosis upgrading service response;

and restarting based on the restart MCU request, and returning a restart MCU response to the SOC through the inter-core communication interface.

13. A program burning method is applied to a diagnosis device and comprises the following steps:

when a target upgrading object in a vehicle-mounted terminal is determined to be a Micro Control Unit (MCU), a diagnosis upgrading service request is sent to a System On Chip (SOC) in the vehicle-mounted terminal based on the memory address range of the MCU;

receiving an upgrading condition verification result of the MCU returned by the SOC; the upgrading condition verification result is returned after the SOC verifies whether the MCU meets the upgrading condition or not when the SOC determines that the target upgrading object is the MCU based on the memory address range in the diagnosis upgrading service request;

and when the MCU meets the upgrading condition based on the upgrading condition verification result, sending upgrading program data of the MCU to the SOC so that the SOC sends the upgrading program data to the MCU through an inter-core communication interface for program burning.

14. The program burning method of claim 13, wherein before sending the upgraded program data of the MCU to the SOC, the method further comprises:

sending a secure access request to the SOC;

receiving a security verification result returned after the SOC performs security verification on the diagnostic equipment based on a negotiated security access algorithm;

determining that security verification passes based on the security verification result.

15. The program burning method of claim 13, wherein before sending the upgraded program data of the MCU to the SOC, the method further comprises:

sending a memory erasing request to the SOC;

receiving the memory erasing response forwarded by the SOC; the memory erasing response is that the SOC forwards the memory erasing request to the MCU through the inter-core communication interface, and the MCU returns to the SOC through the inter-core communication interface after erasing the memory based on the memory erasing request;

and determining that the MCU memory is erased based on the memory erasing response.

16. The program burning method of any one of claims 13 to 15, wherein after sending the upgrade program data of the MCU to the SOC, the method further comprises:

sending an upgrade mode switching request to the SOC;

receiving an upgrading mode switching response forwarded by the SOC; the upgrading mode switching response is that the SOC forwards the upgrading mode switching request to the MCU through the inter-core communication interface, and the MCU returns to the SOC through the inter-core communication interface after switching to an upgrading mode based on the upgrading mode switching request;

and determining that the MCU upgrading mode is completely switched based on the upgrading mode switching response.

17. The program burning method of any one of claims 13 to 15, wherein after sending the upgrade program data of the MCU to the SOC, the method further comprises:

receiving a diagnosis upgrading service response forwarded by the SOC; the diagnosis upgrading service response is that the MCU returns to the SOC through the inter-core communication interface after program burning is carried out on the basis of the upgrading program data;

after the MCU program is completely burnt based on the diagnosis upgrading service response, an MCU restarting request is sent to the SOC;

receiving a restart MCU response forwarded by the SOC; the MCU returns to the SOC through the inter-core communication interface after restarting based on the restart MCU request;

and determining that the MCU is restarted based on the restart MCU response.

18. A program burning device is characterized in that the program burning device is applied to a System On Chip (SOC) in a vehicle-mounted terminal, and comprises the following components:

the upgrading verification unit is used for verifying whether the MCU meets the upgrading condition or not when the target upgrading object is determined to be the MCU based on the memory address range in the diagnosis upgrading service request, and returning an upgrading condition verification result to the diagnosis equipment;

the data receiving unit is used for receiving upgrade program data sent by the diagnosis equipment when the MCU meets the upgrade condition determined based on the upgrade condition verification result;

and the data forwarding unit is used for sending the upgrading program data to the MCU through an inter-core communication interface for program burning.

19. The utility model provides a program burns and writes device which characterized in that, is applied to the little the control unit MCU among the vehicle mounted terminal, includes:

the system comprises a data receiving unit, a data processing unit and a data processing unit, wherein the data receiving unit is used for receiving upgrading program data sent by a system-on-chip SOC through an inter-core communication interface; the upgrading program data is that the SOC determines that a target upgrading object is the MCU based on a memory address range in a diagnosis upgrading service request sent by diagnosis equipment, and after an upgrading condition verification result of the MCU is returned to the diagnosis equipment, the diagnosis equipment determines that the MCU meets the upgrading condition based on the upgrading condition verification result and sends the upgrading condition to the SOC;

20. A program burning device is applied to a diagnosis device and comprises:

the system comprises a request sending unit, a diagnosis upgrading unit and a judging unit, wherein the request sending unit is used for sending a diagnosis upgrading service request to a System On Chip (SOC) in the vehicle-mounted terminal based on the memory address range of a Micro Control Unit (MCU) when a target upgrading object in the vehicle-mounted terminal is determined to be the MCU;

the verification receiving unit is used for receiving the upgrading condition verification result of the MCU returned by the SOC; the upgrading condition verification result is returned after the SOC verifies whether the MCU meets the upgrading condition or not when the SOC determines that the target upgrading object is the MCU based on the memory address range in the diagnosis upgrading service request;

and the data transmitting unit is used for transmitting the upgrading program data of the MCU to the SOC when the MCU meets the upgrading condition based on the upgrading condition verification result so that the SOC transmits the upgrading program data to the MCU through an inter-core communication interface for program burning.

21. A vehicle-mounted terminal characterized by comprising: the system-on-chip (SOC) comprises a memory, a system-on-chip (SOC) and a Micro Control Unit (MCU), wherein the memory is stored with a first computer program capable of running on the SOC and a second computer program capable of running on the MCU, the SOC realizes the program burning method according to any one of claims 1-7 when executing the first computer program, and the MCU realizes the program burning method according to any one of claims 8-12 when executing the second computer program.

22. A diagnostic device, comprising: a memory on which is stored a computer program operable on the processor, and a processor implementing the program burning method according to any one of claims 13-17 when executing the computer program.

23. A computer-readable storage medium storing computer instructions which, when executed, implement the program burning method according to any one of claims 1 to 7; or implementing a program burning method as claimed in any one of claims 8-12; or implementing a program burning method as claimed in any one of claims 13-17.