CAN (Controller Area Network) communication embedded software upgrading method, device, equipment and product thereof

Abstract

The invention discloses a CAN communication embedded software upgrading method, device and equipment and a product thereof, and relates to the field of embedded communication.The CAN communication embedded software upgrading method comprises the steps that serial number division is conducted on data to be transmitted according to the allowable length uploaded by the embedded equipment, and a data block set is obtained, and selecting a to-be-transmitted data block from the data block set, transmitting the to-be-transmitted data block, and checking the to-be-transmitted data block when the transmission of the to-be-transmitted data block is finished. Compared with the prior art in which the upper computer sends all upgrade firmware packets at one time and then carries out integrity verification or the upper computer sends a frame of upgrade firmware and the embedded device needs to return a frame of response, the method has the advantages that the upper computer divides the upgrade data block into a plurality of to-be-transmitted data blocks and sends the to-be-transmitted data blocks to the embedded device; and after the transmission of the to-be-transmitted data block is finished, the CRC check is performed to judge whether the data transmission is correct or not, so that the data transmission efficiency is improved, and the reliability of software upgrading is enhanced.

Description

Technical Field

[0001] The present application relates to the field of embedded communication technology, and in particular to a CAN communication embedded software upgrade method, device, equipment and product thereof. Background Art

[0002] At present, with the rapid development of computer technology and integrated circuit technology, the performance of microprocessors is becoming more and more powerful, and the capacity of memory is becoming larger and larger, which provides strong technical support for the development and application of embedded devices. Since the Internet of Things technology enables various smart devices to connect and interact with each other, embedded devices, as the core of the Internet of Things devices, have promoted the widespread application of embedded devices in smart homes, smart cities, industrial automation and other fields.

[0003] However, in existing technologies, when upgrading embedded devices using CAN (Controller Area Network) communication, either all upgrade firmware packages are sent one at a time, frame by frame, without the embedded device needing to respond to each frame. Finally, a firmware integrity check is performed. If a single CAN data frame is erroneous during transmission, the entire upgrade process fails. Alternatively, each firmware upgrade frame sent requires the embedded device to respond with a frame. This one-on-one response method is very inefficient and lengthy. Summary of the Invention

[0004] The main purpose of this application is to provide a CAN communication embedded software upgrade method, device, equipment and its products, aiming to solve the technical problems of low efficiency and poor reliability in the existing technology for software upgrade of embedded devices through CAN communication.

[0005] To achieve the above objectives, the present application provides a CAN communication embedded software upgrade method, the CAN communication embedded software upgrade method comprising:

[0006] Divide the data to be transmitted into a set of data blocks according to the allowed length of the data uploaded by the embedded device;

[0007] Selecting a data block to be transmitted from the data block set;

[0008] Transmitting the data block to be transmitted;

[0009] When the transmission of the data block to be transmitted is completed, the data block to be transmitted is checked.

[0010] Optionally, before the step of dividing the data to be transmitted according to the allowed length uploaded by the embedded device to obtain a set of data blocks, the method further includes:

[0011] Send the request data block to the embedded device;

[0012] Receive the response frame returned by the embedded device;

[0013] If the device type in the response frame is the same as that of the embedded device and the embedded device is in the upgrade start state, the data block to be transmitted is sent to the embedded device;

[0014] If the data field of the data block to be transmitted meets the preset upgrade condition, the allowed length returned by the embedded device is received.

[0015] Optionally, if the data field of the data block to be transmitted meets the preset upgrade condition, the step of receiving the allowed length returned by the embedded device specifically includes:

[0016] When the device type in the data block to be transmitted is the same as that of the embedded device, the embedded device is in the upgrade start state or the transmission end state, and the data block sequence number is valid, the allowed length returned by the embedded device is received.

[0017] Optionally, the step of performing verification on the data block to be transmitted at the end of transmission specifically includes:

[0018] Send the end data block to the embedded device;

[0019] If the data field of the end data block meets the preset end condition, the data block to be transmitted is checked.

[0020] Optionally, if the data field of the end data block meets a preset end condition, the step of performing verification of the data block to be transmitted specifically includes:

[0021] When the device type in the end data block is the same as the embedded device, the embedded device is in the data transmission state, and the total amount of data received by the embedded device is equal to the end data block length, the data block to be transmitted is checked.

[0022] Optionally, after the step of verifying the data block to be transmitted at the end of the transmission of the data block to be transmitted, the method further includes:

[0023] If the data block to be transmitted is verified to be correct, the fault code returned by the receiving embedded device is a first preset value;

[0024] If the to-be-transmitted data block has a check error, the fault code returned by the receiving embedded device is a second preset value.

[0025] Optionally, after the step of verifying the data block to be transmitted at the end of the transmission of the data block to be transmitted, the method further includes:

[0026] Receive the response frame returned by the embedded device;

[0027] If the fault code in the response frame is the first preset value, the process returns to the step of selecting a data block to be transmitted from the data block set until all data blocks are transmitted.

[0028] In addition, to achieve the above-mentioned purpose, the present application also proposes a CAN communication embedded software upgrade device, the device comprising:

[0029] A partitioning module is used to divide the data to be transmitted into a set of data blocks according to the allowed length uploaded by the embedded device;

[0030] A selection module, configured to select a data block to be transmitted from the data block set;

[0031] A transmission module, configured to transmit the data block to be transmitted;

[0032] The verification module is used to verify the data block to be transmitted when the transmission of the data block to be transmitted is completed.

[0033] In addition, to achieve the above-mentioned purpose, the present application also proposes an embedded device, which includes the CAN communication embedded software upgrade method described above.

[0034] In addition, to achieve the above-mentioned purpose, the present application also proposes a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the CAN communication embedded software upgrade method.

[0035] One or more technical solutions proposed in this application have at least the following effects:

[0036] In the present application, the host computer divides the data to be transmitted into a sequence number according to the allowed length uploaded by the embedded device to obtain a data block set, selects the data block to be transmitted from the data block set, transmits the data block to be transmitted, and verifies the data block to be transmitted after the transmission of the data block to be transmitted is completed. Compared with the prior art in which the host computer sends all the upgrade firmware packages at once and then performs an integrity check, or the host computer sends a frame of upgrade firmware and requires the embedded device to send a frame of response, in the present application, the host computer divides the upgrade data block into multiple data blocks to be transmitted and sends them to the embedded device. After the transmission of the data blocks to be transmitted is completed, a CRC check is performed to determine whether the data transmission is correct, thereby improving data transmission efficiency and enhancing the reliability of embedded device software upgrades. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0038] Figure 1 This is a flow chart of the first embodiment of the CAN communication embedded software upgrade method proposed in the embodiment of the present application;

[0039] Figure 2 This is a flow chart of the second embodiment of the CAN communication embedded software upgrade method proposed in the embodiment of the present application;

[0040] Figure 3 This is a flow chart of the third embodiment of the CAN communication embedded software upgrade method proposed in the embodiment of the present application;

[0041] Figure 4 This is a flow chart of a fourth embodiment of the CAN communication embedded software upgrade method proposed in the present application;

[0042] Figure 5 This is a schematic diagram of the module structure of the CAN communication embedded software upgrade device according to an embodiment of the present application;

[0043] Figure 6 This is the flow chart of the interaction between the host computer and the embedded device for upgrading the firmware in this application.

[0044] Description of Figure Numbers:

[0045] Label name Label name 10 Divide modules 20 Select Module 30 Transmission Module 40 Verification Module

[0046] The realization of the objectives, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0047] It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application.

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

[0049] In addition, the descriptions of "first", "second", etc. in this application are for descriptive purposes only and should not be understood as indicating or implying their relative importance or implicitly indicating the number of the technical features indicated. Therefore, the features defined as "first" or "second" may explicitly or implicitly include at least one of such features. In addition, the technical solutions between the various embodiments can be combined with each other, but this must be based on the fact that they can be implemented by ordinary technicians in this field. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection required by this application.

[0050] The main solution of the embodiment of the present application is: the host computer divides the upgrade data block into multiple data blocks to be transmitted and sends them to the embedded device, and performs CRC check after the transmission of the data blocks to be transmitted is completed to determine whether the data transmission is correct.

[0051] In this embodiment, for ease of description, the following description will be made with the host computer as the execution entity.

[0052] Currently, when using CAN communication to upgrade embedded devices, existing technologies either send all upgrade firmware packages one by one at a time, without requiring the embedded device to respond to each frame. Finally, a firmware integrity check is performed. If a single CAN data frame is erroneous during transmission, the entire upgrade process fails. Alternatively, each firmware upgrade frame sent requires the embedded device to respond with a frame. This question-and-answer approach is highly inefficient and lengthy.

[0053] The present application provides a solution, in which a host computer divides the data to be transmitted into serial numbers according to the allowed length uploaded by the embedded device to obtain a data block set, selects the data block to be transmitted from the data block set, transmits the data block to be transmitted, and at the end of the transmission of the data block to be transmitted, verifies the data block to be transmitted to determine whether the data transmission is correct, thereby improving the data transmission efficiency and enhancing the reliability of the embedded device software upgrade.

[0054] Based on this, an embodiment of the present application provides a CAN communication embedded software upgrade method.

[0055] Reference Figure 1 , Figure 1 This is a flow chart of the first embodiment of the CAN communication embedded software upgrade method proposed in the embodiment of the present application.

[0056] Considering that in the existing technology, the host computer sends all the upgrade firmware packages at one time and then performs integrity verification, or the host computer sends a frame of upgrade firmware and the embedded device must respond with a frame, in order to improve the data transmission efficiency and enhance the reliability of software upgrades, such as Figure 1As shown, the CAN communication embedded software upgrade method of this embodiment includes steps S10 to S40:

[0057] Step S10: Sequence the data to be transmitted according to the allowed length uploaded by the embedded device to obtain a data block set.

[0058] It should be noted that the embedded device sends a response frame to the host computer. The frame ID of the response frame is 0x18FFFFE8, the second byte is the device type, and the seventh and eighth bytes of the data field of the response frame are the data block length DLEN, which is the allowed length.

[0059] It is understandable that the sequence number is determined according to the number of data blocks to be transmitted, and the number of data blocks to be transmitted is determined according to the allowed length of the uploaded data by the embedded device.

[0060] In a specific implementation, the host computer divides the data to be transmitted into serial numbers according to the allowed length uploaded by the embedded device to obtain a set of data blocks.

[0061] Step S20: Selecting a data block to be transmitted from the data block set.

[0062] It should be noted that the selection principle can be selected in order according to the divided sequence numbers, or can be set according to actual conditions. This embodiment does not limit this. The data blocks to be transmitted include upgrade data.

[0063] In a specific implementation, the host computer selects the data block to be transmitted from the data block set.

[0064] Step S30: Transmit the data block to be transmitted.

[0065] It should be noted that the host computer transmits data through CAN communication (serial communication protocol).

[0066] It should be noted that the data to be transmitted is divided into multiple data blocks to be transmitted. The frame ID of the data block to be transmitted is 0x18FFE8FF. The first and second bytes of the data field are the frame number. The frame number starts from 1. The highest 4 bits of the first byte of the data field are always 0. The frame number ranges from 1 to 4095. The third to eighth bytes of the data field are the upgrade data.

[0067] In a specific implementation, the host computer sends the data block to be transmitted to the embedded device through CAN communication.

[0068] Step S40: After the transmission of the data block to be transmitted is completed, verify the data block to be transmitted.

[0069] It should be noted that the check can be a CRC check, or can be set according to actual conditions, which is not limited in this embodiment.

[0070] It is understandable that CRC check is a cyclic redundancy check (Cyclic Redundancy Check). CRC check is the most commonly used error-checking code in the field of data communications. It performs polynomial calculations on data and appends the results to the end of the frame to ensure the correctness and integrity of data transmission.

[0071] In a specific implementation, the host computer performs verification on the data block to be transmitted when the transmission of the data block to be transmitted is completed.

[0072] In this embodiment, the host computer divides the data to be transmitted into serial numbers according to the allowed length uploaded by the embedded device to obtain a data block set, selects the data block to be transmitted from the data block set, and sends the data block to be transmitted to the embedded device through CAN communication. When the transmission of the data block to be transmitted is completed, the data block to be transmitted is verified, thereby improving the data transmission efficiency and enhancing the reliability of the embedded device software upgrade.

[0073] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the first embodiment can be referred to the above introduction and will not be described in detail later. Figure 2 , Figure 2 This is a flow chart of the second embodiment of the CAN communication embedded software upgrade method proposed in the embodiment of the present application.

[0074] Considering the circumstances under which the embedded device performs software upgrades, and then in order to determine whether the embedded device enters the upgrade start state, such as Figure 2 As shown, in this embodiment, before step S10, the following steps are further included:

[0075] Step S101: Send a request data block to the embedded device.

[0076] It should be noted that the frame ID of the data block request frame is 0x18FFE8FF, and the first byte of the data field of the data block request is the command code 0xFF.

[0077] Step S102: Receive a response frame returned by the embedded device.

[0078] It should be noted that after receiving the request data block, the embedded device sends a response frame to the host computer. The frame ID is 0x18FFFFE8. The first byte of the data field in the response data is the command code 0xFF, the second byte is the device type, and the third byte is the current status.

[0079] Step S103: If the device type in the response frame is the same as that of the embedded device and the embedded device is in the upgrade start state, the data block to be transmitted is sent to the embedded device.

[0080] It should be noted that if the embedded device allows upgrading, it will execute the reset instruction and jump to the BOOT state to run, otherwise it will stay in the APP state. The BOOT state means that the embedded device is in the boot process or boot loader state, and the APP state means that the main application of the embedded device is in the running state. After the embedded device is in the BOOT state and receives the request data block from the host computer, it initializes the parameters required for the upgrade and sets the working state to the start upgrade state; the host computer determines whether the device type in the response frame returned by the embedded device is correct. If the device type is correct, it continues to send request data blocks until the embedded device returns to the BOOT state.

[0081] Step S104: If the data field of the data block to be transmitted meets the preset upgrade condition, the allowed length returned by the embedded device is received.

[0082] It should be noted that the data field of the data block to be transmitted in this embodiment includes: command code, device type and current data block sequence number. For example: the first byte of the data field is the command code 0xFE, the second byte is the device type, and the fifth to eighth bytes are the current data block sequence number.

[0083] In the specific implementation, the host computer sends a request data block to the embedded device and receives a response frame returned by the embedded device. If the device type in the response frame is the same as that of the embedded device and the embedded device is in the start-up state, the host computer sends the data block to be transmitted to the embedded device. If the data field of the data block to be transmitted meets the preset upgrade conditions, the host computer receives the allowed length returned by the embedded device, thereby obtaining the upgrade data block length required by the embedded device.

[0084] Furthermore, considering the specific conditions of the preset upgrade, step S104 specifically includes:

[0085] Step S1041: When the device type in the data block to be transmitted is the same as that of the embedded device, the embedded device is in the upgrade start state or the transmission end state, and the data block sequence number is valid, the allowed length returned by the embedded device is received.

[0086] It should be noted that the transmission completion state means that the host computer has completed sending the data block to be transmitted to the embedded device and the data block to be transmitted has been verified to be correct.

[0087] In a specific implementation, after the host computer receives the status of BOOT returned by the embedded device, it sends the data block to be transmitted to the embedded device. The frame ID of the data block to be transmitted is 0x18FFE8FF, the first byte of the data field is the command code 0xFE, the second byte is the device type, and the fifth to eighth bytes are the current data block sequence number, starting from 1. After receiving the data block to be transmitted, the embedded device determines whether the device type is the same. If the device type is not the same, the original state remains unchanged. If the device type is the same, it determines whether the working state is the start upgrade state or the end transmission state. If so, it determines whether the sequence number of the data block to be transmitted is valid. If the sequence number of the data block to be transmitted is invalid, the fault code 100 in the fourth byte of the data field is returned. If the sequence number of the data block to be transmitted is valid, the data block length DLEN is returned in the seventh to eighth bytes of the data field. Subsequently, the host computer transmits the data block to be transmitted according to the data block length and sets the working state to the data transmission state, thereby improving the data transmission efficiency.

[0088] Based on the second embodiment of the present application, in the third embodiment of the present application, the same or similar contents as those in the second embodiment can be referred to the above introduction and will not be described in detail later. Figure 3 , Figure 3 This is a flow chart of the third embodiment of the CAN communication embedded software upgrade method proposed in the embodiment of the present application.

[0089] Considering the working state of the host computer when the transmission of the data block to be transmitted is completed, step S40 specifically includes:

[0090] Step S41: Sending the end data block to the embedded device.

[0091] It should be noted that the end data block is the last data block to be transmitted in the data block set.

[0092] Step S42: If the data field of the end data block meets the preset end condition, the data block to be transmitted is checked.

[0093] In a specific implementation, the host computer sends an end data block to the embedded device. If the data field of the end data block meets the preset end condition, the data block to be transmitted is verified, thereby enhancing the reliability of the embedded device software upgrade.

[0094] Furthermore, considering the specific conditions for the preset end, step S42 specifically includes:

[0095] Step S421: When the device type in the end data block is the same as the embedded device, the embedded device is in the data transmission state, and the total amount of data received by the embedded device is equal to the end data block length, the data block to be transmitted is checked.

[0096] It should be noted that after the embedded device receives the data block to be transmitted, it determines whether the current working state is the data transmission state. If it is not in the data transmission state, the upgrade data is not cached. If it is in the data transmission state, the response frame is not returned. The upgrade data of the 3rd to 8th bytes of the data field of the received data block to be transmitted is saved to the internal memory for subsequent use, and the total amount of data received RLEN is accumulated at the same time.

[0097] In the specific implementation, after the data block transmission is complete, the host computer upgrading the firmware sends an end data block to the embedded device. The frame ID is 0x18FFE8FF. The first byte of the data field is the command code 0xFD, the second byte is the device type, and the fifth and sixth bytes are the end data block length TLEN. The last data block is the actual remaining length of the upgraded firmware, which is the same as DLEN in other cases. The seventh and eighth bytes are the end data block CRC checksum. After receiving the data, the embedded device determines whether the device type is the same. If not, it maintains the original state. Otherwise, it determines whether the operating state is transmitting data. If not, it returns the error code 105 in the fourth byte of the data field. If the state is correct, it determines whether the end data block length TLEN equals the total amount of data received RLEN. If not, it returns the error code 101 in the fourth byte of the data field. If they are equal, it performs a check of the data block to be transmitted, further ensuring the reliability of the embedded device software upgrade.

[0098] Based on the third embodiment of the present application, in the fourth embodiment of the present application, the same or similar contents as those in the third embodiment can be referred to the above introduction and will not be described in detail later. Figure 4 , Figure 4 This is a flow chart of the fourth embodiment of the CAN communication embedded software upgrade method proposed in the embodiments of the present application.

[0099] Considering the verification of the data block to be transmitted, step S40 further includes:

[0100] Step S401: If the data block to be transmitted is verified to be correct, the fault code returned by the receiving embedded device is a first preset value.

[0101] Step S402: If the to-be-transmitted data block has a checksum error, the fault code returned by the receiving embedded device is a second preset value.

[0102] It should be noted that the first preset value and the second preset value can be set according to actual conditions, and this embodiment does not limit them.

[0103] In the specific implementation, the embedded device calculates the CRC check value of the end data block, compares the calculated CRC check value with the CRC check value of the received end data block to see if they are the same. If the CRCs are different, the 4th byte fault code 102 of the data field is returned. If the CRCs are the same, the cached upgrade data is written to the internal FLASH flash memory of the embedded device. If the write is successful, the 4th byte fault code of the data field is returned as 0, otherwise the fault code is 103, thereby enhancing the reliability of the embedded device software upgrade.

[0104] Furthermore, considering whether the data block to be transmitted is completely transmitted, the following steps are further included after step S40:

[0105] Step S403: Receive a response frame returned by the embedded device.

[0106] Step S404: If the fault code in the response frame is the first preset value, the process returns to the step of selecting a data block to be transmitted from the data block set until all data blocks are transmitted.

[0107] It should be noted that if Figure 6 As shown, in this application, the upgrade request frame is the request data block, the data block data frame is the data block to be transmitted, and the transmission end frame is the end data block. After all the data blocks to be transmitted are transmitted, the host computer that upgrades the firmware sends an upgrade end frame with a frame ID of 0x18FFE8FF, the first byte of the data field is the command code 0xFC, and the second byte is the device type. After receiving the data, the embedded device determines whether the device type is the same. If the device type is different, it maintains the original state. Otherwise, it returns a response frame with an ID of 0x18FFFFE8, the first byte of the data field is the command code 0xFC, and the second byte is the device type. Finally, the APP firmware is started. After the host computer that upgrades the firmware receives the response, it prompts the user that the upgrade is complete.

[0108] In the specific implementation, the embedded device returns a response frame with the ID 0x18FFFFE8. The first byte of the data field is the command code 0xFD, the second byte is the device type, the fourth byte is the fault code, and the working state is set to the end of the transmission. After receiving the response data frame, the host computer indicates a fault if the fault code is not equal to 0 and ends the upgrade process. Otherwise, it returns to the step of selecting the data block to be transmitted from the data block set until all the data blocks to be transmitted are transmitted, thus ensuring the integrity of the upgrade data transmission.

[0109] This application also provides a CAN communication embedded software upgrade device, please refer to Figure 5 , Figure 5 This is a schematic diagram of the module structure of the CAN communication embedded software upgrade device according to an embodiment of the present application, the device includes:

[0110] A division module 10 is used to divide the data to be transmitted into a set of data blocks according to the allowed length of the data uploaded by the embedded device;

[0111] A selection module 20, configured to select a data block to be transmitted from the data block set;

[0112] The transmission module 30 is used to transmit the data block to be transmitted;

[0113] The verification module 40 is configured to verify the data block to be transmitted when the transmission of the data block to be transmitted is completed.

[0114] The present application also proposes an embedded device, which includes the above-mentioned CAN communication embedded software upgrade method.

[0115] The present application also provides a computer program product, comprising a computer program, which, when executed by a processor, implements the steps of the above-mentioned CAN communication embedded software upgrade method.

[0116] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A CAN communication embedded software upgrade method, characterized in that: The CAN communication embedded software upgrade method comprises: The data to be transmitted is divided into a set of data blocks by serial numbers according to the allowed length uploaded by the embedded device; Selecting a data block to be transmitted from the data block set; Transmitting the data block to be transmitted; When the transmission of the data block to be transmitted is completed, the data block to be transmitted is checked.

2. The CAN communication embedded software upgrade method according to claim 1, characterized in that: Before the step of dividing the data to be transmitted according to the allowed length uploaded by the embedded device to obtain a data block set, the method further includes: Send the request data block to the embedded device; Receive the response frame returned by the embedded device; If the device type in the response frame is the same as that of the embedded device and the embedded device is in the state of starting to upgrade, the data block to be transmitted is sent to the embedded device; If the data field of the data block to be transmitted meets the preset upgrade condition, the allowed length returned by the embedded device is received.

3. The CAN communication embedded software upgrade method as claimed in claim 2, characterized in that: If the data domain of the data block to be transmitted meets the preset upgrade condition, the step of receiving the allowed length returned by the embedded device specifically includes: When the device type in the data block to be transmitted is the same as that of the embedded device, the embedded device is in the start-upgrade state or the end-of-transmission state, and the data block sequence number is valid, the allowed length returned by the embedded device is received.

4. The CAN communication embedded software upgrade method according to claim 1, characterized in that: The step of performing verification of the data block to be transmitted at the end of the transmission of the data block to be transmitted specifically includes: Send the end data block to the embedded device; If the data field of the end data block meets the preset end condition, the data block to be transmitted is checked.

5. The CAN communication embedded software upgrade method as claimed in claim 4, characterized in that: If the data field of the end data block meets the preset end condition, the step of checking the data block to be transmitted specifically includes: When the device type in the end data block is the same as the embedded device, the embedded device is in the data transmission state, and the total amount of data received by the embedded device is equal to the end data block length, the data block to be transmitted is checked.

6. The CAN communication embedded software upgrade method according to claim 1, characterized in that: After the step of checking the data block to be transmitted at the end of the transmission of the data block to be transmitted, the method further includes: If the data block to be transmitted is verified to be correct, the fault code returned by the receiving embedded device is a first preset value; If the to-be-transmitted data block has a check error, the fault code returned by the receiving embedded device is a second preset value.

7. The CAN communication embedded software upgrade method as claimed in claim 6, characterized in that: After the step of checking the data block to be transmitted at the end of the transmission of the data block to be transmitted, the method further includes: Receive the response frame returned by the embedded device; If the fault code in the response frame is the first preset value, the process returns to the step of selecting a data block to be transmitted from the data block set until all data blocks are transmitted.

8. A CAN communication embedded software upgrade device, characterized in that: The device comprises: A division module, used for dividing the data to be transmitted into a set of data blocks according to the allowed length uploaded by the embedded device; A selection module, used for selecting a data block to be transmitted from the data block set; A transmission module, used for transmitting the data block to be transmitted; The verification module is used to verify the data block to be transmitted when the transmission of the data block to be transmitted is completed.

9. An embedded device, characterized in that: The embedded device includes the CAN communication embedded software upgrade method according to any one of claims 1 to 7.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the CAN communication embedded software upgrade method according to any one of claims 1 to 7 are implemented.

Images