CN117908917A - Boot program self-refreshing method, vehicle controller, readable storage medium and vehicle - Google Patents
Boot program self-refreshing method, vehicle controller, readable storage medium and vehicle Download PDFInfo
- Publication number
- CN117908917A CN117908917A CN202311749298.1A CN202311749298A CN117908917A CN 117908917 A CN117908917 A CN 117908917A CN 202311749298 A CN202311749298 A CN 202311749298A CN 117908917 A CN117908917 A CN 117908917A
- Authority
- CN
- China
- Prior art keywords
- boot program
- boot
- value
- checksum
- preset
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 81
- 238000000547 structure data Methods 0.000 claims description 34
- 238000004590 computer program Methods 0.000 claims description 12
- 230000008569 process Effects 0.000 abstract description 13
- 239000011449 brick Substances 0.000 abstract description 7
- 230000015572 biosynthetic process Effects 0.000 abstract description 3
- 238000010586 diagram Methods 0.000 description 17
- 230000009286 beneficial effect Effects 0.000 description 11
- 238000004891 communication Methods 0.000 description 10
- 230000006870 function Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000012795 verification Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 239000000463 material Substances 0.000 description 2
- 239000013307 optical fiber Substances 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000000802 evaporation-induced self-assembly Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
Abstract
The invention provides a Boot program self-refreshing method, a vehicle controller, a readable storage medium and a vehicle, wherein the method comprises the following steps: copying the old version Boot program stored in the source Boot storage block into the backup Boot storage block according to the acquired Boot program self-refreshing instruction; erasing old-version Boot programs stored in the source Boot storage block, and storing new-version Boot programs into the source Boot storage block; after the power is on again, the BootRom program stored at the starting address of the ARM chip is adopted to check the BootRom program stored in the source Bootstorage block and/or the backup Bootstorage block, and the Bootprogram with successful check is operated. The invention can reduce the risk of brick formation in the ECU self-refreshing process, avoid the probability of replacing accessories and reduce the cost after sale.
Description
Technical Field
The invention relates to the technical field of software program refreshing, in particular to a Boot program self-refreshing method, a vehicle controller, a readable storage medium and a vehicle.
Background
With the rapid development of automobile electronics, an arm core chip is gradually and widely applied to an automobile controller/sensor, and in automobile software, a boot is taken as a main role of refreshing APP, is indispensable software in the automobile controller/sensor, is also a part of customer demands, and in order to distinguish the boot, some projects are called CB (Customer Boot) according to a customer refreshing flow and requirements. At present, a whole vehicle factory only has refreshing standard requirements on APP software, but does not have refreshing standard on Boot, so that the APP can be updated only through CB for the controllers of the produced and packaged shells, whether in the whole vehicle factory or in the client. This causes a problem that when the Bug occurs in the mass-produced controller Boot software, there is a great difficulty in updating the Boot software.
It should be noted that the information disclosed in this background section is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.
Disclosure of Invention
The invention aims to provide a Boot program self-refreshing method, a vehicle controller, a readable storage medium and a vehicle, which can reduce the risk of brick formation in the ECU self-refreshing process, avoid the probability of accessory replacement and reduce the cost after sale.
In order to achieve the above object, the present invention provides a Boot program self-refresh method, including:
copying the old version Boot program stored in the source Boot storage block into the backup Boot storage block according to the acquired Boot program self-refreshing instruction;
erasing the old-version Boot program stored in the source Boot storage block, and storing a new-version Boot program into the source Boot storage block;
After the power is on again, the BootRom program stored at the starting address of the ARM chip is adopted to check the BootRom program stored in the source Bootstorage block and/or the backup Bootstorage block, and the Bootprogram with successful check is operated.
Optionally, the verifying the Boot program stored in the source Boot storage block and/or the backup Boot storage block includes:
Checking the Boot program according to the head structure data of the Boot program;
When the old version Boot program stored in the source Boot storage block is copied into the backup Boot storage block, the method further comprises the following steps:
and updating the head structure data of the old version Boot program stored in the backup Boot storage block.
Optionally, the header structure data includes a start code address, a valid flag bit, a checksum start address, a checksum end address, a preset checksum value, an inverse value of the preset checksum value, a preset header structure check value, and an inverse value of the preset header structure check value.
Optionally, the verifying the Boot program according to the header structure data of the Boot program includes:
checking the validity of the Boot program according to the valid flag bit in the head structure data of the Boot program;
if the validity check is successful, checking the integrity of the code of the Boot program according to the preset checksum value and the inverse value of the preset checksum value;
If the integrity check of the code of the Boot program is successful, checking the integrity of the header structure data of the Boot program according to the preset header structure check value and the inverse value of the preset header structure check value;
And if the integrity check of the head structure data is successful, judging that the Boot program is successful in check.
Optionally, the verifying the integrity of the code of the Boot program according to the preset checksum value and the inverse value of the preset checksum value includes:
Acquiring a calculated checksum CRC32 value of a corresponding storage segment and a negation value of the calculated checksum CRC32 value according to the checksum starting address and the checksum ending address;
And if the calculated checksum CRC32 value is consistent with the preset checksum value and the inverse value of the calculated checksum CRC32 value is consistent with the inverse value of the preset checksum value, judging that the code of the Boot program is complete.
Optionally, the verifying the integrity of the header structure data of the Boot program according to the preset header structure verification value and the inverse value of the preset header structure verification value includes:
obtaining a calculated head structure CRC32 value and a calculated head structure CRC32 value according to the starting code address, the valid flag bit, the checksum starting address, the checksum ending address, the preset checksum value and the preset checksum value;
And if the calculated head structure CRC32 value is consistent with the preset head structure check value, and the inverse value of the calculated head structure CRC32 value is consistent with the inverse value of the preset head structure check value, judging that the head structure data of the Boot program is complete.
Optionally, starting address information of the source Boot storage block and the backup Boot storage block are configured in the BootRom program, and the BootRom program is configured to preferentially check the Boot program stored in the source Boot storage block.
In order to achieve the above object, the present invention further provides a vehicle controller, including a processor and a memory, where the memory stores a computer program, and when the computer program is executed by the processor, the Boot program self-refresh method is implemented.
In order to achieve the above object, the present invention further provides a readable storage medium, in which a computer program is stored, the computer program implementing the Boot program self-refresh method described above when executed by a processor.
To achieve the above object, the present invention also provides a vehicle comprising the vehicle controller described above or the readable storage medium described above.
Compared with the prior art, the Boot program self-refreshing method, the vehicle controller, the readable storage medium and the vehicle provided by the invention have the following beneficial effects:
According to the Boot program self-refreshing method provided by the invention, the old version Boot program stored in the source Boot storage block is copied into the backup Boot storage block according to the acquired Boot program self-refreshing instruction; erasing the old-version Boot program stored in the source Boot storage block, and storing a new-version Boot program into the source Boot storage block; and finally, after the power is on again, the BootRom program stored at the starting address of the ARM chip is adopted to check the BootRoot program stored in the source Bootmemory block and/or the backup Bootmemory block, and the BootRoot program which is checked successfully is operated. In the Boot program self-refreshing method provided by the invention, the old version Boot program is copied into the backup Boot storage block in the self-refreshing process of the Boot program, then the old version Boot program is erased from the source Boot storage block, and the new version Boot program is stored into the source Boot storage block, so that when the power-off phenomenon occurs in the Boot program updating process, the new version Boot program stored in the source Boot storage block is incomplete, the Boot program can verify the Boot program stored in the backup Boot storage block after the Boot program is electrified again, and the backup Boot program (namely the Boot program stored in the backup Boot storage block) is operated after the Boot program is successfully verified, so that a controller (such as a vehicle ECU) has refreshing capability all the time, the risk that the Boot program cannot normally run any more, the controller is in a brick form can be effectively reduced, and the after-sale cost is effectively reduced. In addition, the Boot program self-refreshing method provided by the invention can carry out self-refreshing according to the client refreshing flow, and when the Boot program after the downloading appears Bug, the client can finish refreshing the Boot program, thereby improving the after-sale efficiency.
Because the vehicle controller, the readable storage medium and the vehicle provided by the invention belong to the same inventive concept as the Boot program self-refreshing method provided by the invention, the vehicle controller, the readable storage medium and the vehicle provided by the invention have at least all the beneficial effects of the Boot program self-refreshing method provided by the invention, and the description of the beneficial effects of the Boot program self-refreshing method provided by the invention can be referred to in detail, so that the beneficial effects of the vehicle controller, the readable storage medium and the vehicle provided by the invention are not repeated one by one.
Drawings
FIG. 1 is a schematic diagram of SB refresh CB;
FIG. 2 is a schematic diagram of a Boot refresh Boot;
FIG. 3 is a schematic flow chart of a Boot self-refreshing method according to an embodiment of the present invention;
fig. 4 is a schematic diagram of a BootRom program setting position in a Boot program self-refreshing method according to an embodiment of the present invention;
fig. 5 is a schematic diagram of backup of an old Boot program in the Boot program self-refreshing method according to an embodiment of the present invention;
FIG. 6 is a schematic diagram of a new version of Boot program refreshed in the Boot program self-refreshing method provided by an embodiment of the present invention;
fig. 7 is a schematic block diagram of a vehicle controller according to an embodiment of the invention.
Detailed Description
The Boot program self-refreshing method, the vehicle controller, the readable storage medium and the vehicle provided by the invention are further described in detail below with reference to the accompanying drawings and the detailed description. The advantages and features of the present invention will become more apparent from the following description. It should be noted that the drawings are in a very simplified form and are all to a non-precise scale, and are merely intended to facilitate a convenient and clear description of the objects provided by the present invention. For a better understanding of the invention with objects, features and advantages, refer to the drawings. It should be understood that the structures, proportions, sizes, etc. shown in the drawings are shown only in connection with the present disclosure for the understanding and reading of the present disclosure, and are not intended to limit the scope of the invention, which is defined by the appended claims, and any structural modifications, proportional changes, or dimensional adjustments, which may be made by the present disclosure, should fall within the scope of the present disclosure under the same or similar circumstances as the effects and objectives attained by the present invention.
It is noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element. The singular forms "a," "an," and "the" include plural referents, the term "or" is generally used in the sense of comprising "and/or" and the term "several" is generally used in the sense of comprising "at least one," the term "at least two" is generally used in the sense of comprising "two or more," and the term "first," "second," "third," are for descriptive purposes only and are not to be construed as indicating or implying any relative importance or number of features indicated.
Furthermore, in the description herein, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the various embodiments or examples described in this specification and the features of the various embodiments or examples may be combined and combined by those skilled in the art without contradiction.
For easy understanding, the background of the invention will be briefly described before describing the Boot program self-refresh method, the vehicle controller, the readable storage medium and the vehicle.
Most ARM M0+ core chips in the market only support starting from 0 addresses, namely starting from non-multiple addresses, but Boot refreshing is carried out in the following modes according to Boot designed by starting the ARM M0+ core chips from the non-multiple addresses:
(1) SB (startup boot) update CB:
Please refer to fig. 1, which is a schematic diagram of SB refresh CB. As shown in FIG. 1, a Boot will be divided into two software levels, SB and CB; the SB can be developed according to the refreshing requirement of the provider, and can update the APP by using the CB and update the CB by using the SB, so that the CB can be refreshed. However, the scheme needs a larger Flash space, and in the architecture design, not only the Flash resource occupation of the CB is considered, but also the SB resource is reserved, so that the product cost is indirectly increased; and when the SB presents a Bug, the software update of the SB presents a great difficulty.
(2) Boot update Boot:
please refer to fig. 2, which is a schematic diagram of a Boot refresh Boot. As shown in FIG. 2, the Boot has the capability of refreshing the APP, and the Boot also has the capability of refreshing the Boot itself, so that Flash in the Boot area can be refreshed while the APP is refreshed, the refreshing mode can be kept consistent with the refreshing APP flow, the refreshing flow of a client is followed, the refreshing is convenient, the development and maintenance costs are low, and additional refreshing engineering is not required to be developed. However, when the Boot self-refreshes and abnormal conditions such as power failure, communication loss and the like occur, the Boot software is not complete any more, the software can not normally run, the controller is in a brick shape, and the refreshing capability is lost.
Based on the above, the core idea of the invention is to provide a Boot program self-refreshing method, a vehicle controller, a readable storage medium and a vehicle, which can reduce the risk of brick formation in the ECU self-refreshing process, avoid the probability of accessory replacement and reduce the cost after sale.
It should be noted that the Boot program self-refreshing method provided by the invention can be applied to the vehicle controller provided by the invention, wherein the vehicle controller can be configured on the vehicle provided by the invention, the vehicle controller comprises an ARM chip, and the ARM chip comprises a flash memory. It should be further noted that, as can be understood by those skilled in the art, the Boot program self-refreshing method provided by the present invention is not only suitable for an ARM m0+ core chip supporting 0 address start, but also suitable for other ARM chips supporting 0 address start.
In order to achieve the above-mentioned idea, the present invention provides a Boot program self-refresh method, please refer to fig. 3, which is a flow chart of the Boot program self-refresh method according to an embodiment of the present invention. As shown in fig. 3, the Boot program self-refreshing method provided by the invention comprises the following steps:
And step S100, copying the old-version Boot program stored in the source Boot storage block into the backup Boot storage block according to the acquired Boot program self-refreshing instruction.
Step 200, erasing the old-version Boot program stored in the source Boot storage block, and storing a new-version Boot program into the source Boot storage block.
And step S300, after the power is turned on again, the BootRom program stored at the starting address of the ARM chip is adopted to check the BootRoot program stored in the source Bootmemory block and/or the backup Bootmemory block, and the BootRoot program with successful check is operated.
In the Boot program self-refreshing method provided by the invention, the old version Boot program is copied into the backup Boot storage block in the self-refreshing process of the Boot program, then the old version Boot program is erased from the source Boot storage block, and the new version Boot program is stored into the source Boot storage block, so that when the power-off phenomenon occurs in the Boot program updating process, the new version Boot program stored in the source Boot storage block is incomplete, the Boot program can verify the Boot program stored in the backup Boot storage block after the Boot program is electrified again, and the backup Boot program (namely the Boot program stored in the backup Boot storage block) is operated after the Boot program is successfully verified, so that a controller (such as a vehicle ECU) has refreshing capability all the time, the risk that the Boot program cannot normally run any more, the controller is in a brick form can be effectively reduced, and the after-sale cost is effectively reduced. In addition, the Boot program self-refreshing method provided by the invention can carry out self-refreshing according to the client refreshing flow, and when the Boot program after the downloading appears Bug, the client can finish refreshing the Boot program, thereby improving the after-sale efficiency.
It should be noted that, as can be understood by those skilled in the art, the Boot program self-refreshing method provided by the invention can be started to be executed based on the Boot program self-refreshing instruction of the user, taking the ECU (vehicle controller) as an example, when the user needs to refresh the Boot program, the user can input the Boot program self-refreshing instruction to the ECU (vehicle controller), and after the ECU (vehicle controller) receives the Boot program self-refreshing instruction, the ECU (vehicle controller) starts to execute the Boot program self-refreshing method provided by the invention. It should be further noted that, as can be understood by those skilled in the art, after the Boot program self-refresh is successful, the Boot program stored in the backup Boot memory block may be deleted to release the memory space, or the Boot program stored in the backup Boot memory block may be deleted when the next Boot program refresh is executed, so as to provide for backup of a new Boot program. In addition, it should be noted that, as understood by those skilled in the art, the backup Boot memory block may be a memory module where a certain APP is located, or may be a reserved memory module, and if the backup Boot memory block is a memory module where a certain APP is located, after the refreshing of the Boot program is completed, the Boot program in the backup Boot memory block needs to be deleted, and then the APP is rewritten.
Please continue to refer to fig. 4, which is a schematic diagram illustrating a BootRom program setup position in a Boot program self-refresh method according to an embodiment of the present invention. As shown in fig. 4, since the BootRom program is set at the start address of the ARM chip, after the ECU (vehicle controller) including the ARM chip is powered on, the first executed program is the BootRom program. Please continue to refer to fig. 5 and fig. 6, wherein fig. 5 is a schematic diagram of a Boot program backup of an old version in the Boot program self-refreshing method according to an embodiment of the present invention; fig. 6 is a schematic diagram of a new version of Boot program refreshed in the Boot program self-refreshing method according to an embodiment of the present invention. As shown in fig. 5 and fig. 6, when the Boot program is used for self-refreshing, the refreshing flow is consistent with the refreshing APP (application program), but before the old-version Boot program is erased, the stored data in the source Boot storage block (namely the old-version Boot program) is copied into the backup Boot storage block. The old-version Boot program stored in the source Boot storage block is erased after the old-version Boot program is copied, then a refreshing flow is continued to refresh the new-version Boot program in the source Boot storage block, and the new-version Boot program is powered on again after the refreshing of the new-version Boot program is completed.
In some exemplary embodiments, the memory block of the BootRom program is the minimum erase unit (not less than 0.5 KB) of Flash memory. Therefore, by selecting the minimum erasing unit of the Flash memory as the memory block of the BootRom program, the self-refresh of the BootRom program can be realized by adopting fewer chip Flash resources, so that the cost of the development stage is reduced.
In some exemplary embodiments, the Boot program is configured with start address information of the source Boot storage block and the backup Boot storage block. Therefore, the Boot program can conveniently verify the Boot program stored in the source Boot storage block and/or the backup Boot storage block based on the initial address information of the source Boot storage block and/or the backup Boot storage block by configuring the initial address information of the source Boot storage block and the backup Boot storage block in the Boot program.
In some exemplary embodiments, the BootRom program is configured to preferentially verify Boot programs stored in the source Boot memory block. Therefore, the BootRom program is set to be used for checking the Boot program stored in the source Boot storage block preferentially, and the Boot program stored in the source Boot storage block can be checked preferentially after the Boot program is successfully self-refreshed, so that a new version Boot program can be operated after the checking is successful. It should be noted that, as can be understood by those skilled in the art, if the Boot program stored in the source Boot storage block is successfully checked by the BootRom program, the BootRom program does not check the Boot program stored in the backup Boot storage block any more; if the Boot program stored in the source Boot storage block is not successfully verified, the Boot program stored in the source Boot storage block is not updated, and the Boot program can continue to verify the Boot program stored in the backup Boot storage block.
In some exemplary embodiments, the verifying the Boot program stored in the source Boot storage block and/or the backup Boot storage block includes:
And verifying the Boot program according to the head structure data of the Boot program.
When the old version Boot program stored in the source Boot storage block is copied into the backup Boot storage block, the method further comprises the following steps:
and updating the head structure data of the old version Boot program stored in the backup Boot storage block.
Therefore, the Boot program is verified according to the head structure data of the Boot program, so that the verification rate and the verification accuracy can be improved. In addition, by updating the head structure data of the old-version Boot program stored in the backup Boot storage block in the process of backing up the old-version Boot program, the head structure data of the Boot program stored in the backup Boot storage block can be ensured to correspond to the backup Boot storage block where the head structure data of the Boot program stored in the backup Boot storage block is located, so that the Boot program can accurately verify the Boot program according to the head structure data of the Boot program.
With continued reference to fig. 4, as shown in fig. 4, in some exemplary embodiments, the header structure data includes a start code address (start code address), a valid flag bit (VALIDFLAG), a checksum start address (checksum START ADDRESS), a checksum end address (checksum END ADDRESS), a predetermined checksum value (checksum crc 32), a reversal value of the predetermined checksum value (checksum crc32 reversal), a predetermined header structure checksum value (HEADER CRC), and a reversal value of the predetermined header structure checksum value (HEADER CRC reversal).
In some exemplary embodiments, the verifying the Boot program according to the header structure data of the Boot program includes:
checking the validity of the Boot program according to the valid flag bit in the head structure data of the Boot program;
if the validity check is successful, checking the integrity of the code of the Boot program according to the preset checksum value and the inverse value of the preset checksum value;
If the integrity check of the code of the Boot program is successful, checking the integrity of the header structure data of the Boot program according to the preset header structure check value and the inverse value of the preset header structure check value;
And if the integrity check of the head structure data is successful, judging that the Boot program is successful in check.
Therefore, the validity of the Boot program is checked firstly, the integrity of the code of the Boot program is checked again, and finally the integrity of the head structure data of the Boot program is checked again, so that the checking speed can be effectively improved, and the checking accuracy can be ensured.
In some exemplary embodiments, the verifying the integrity of the code of the Boot program according to the preset checksum value and the inverse value of the preset checksum value includes:
Acquiring a calculated checksum CRC32 value of a corresponding storage segment and a negation value of the calculated checksum CRC32 value according to the checksum starting address and the checksum ending address;
And if the calculated checksum CRC32 value is consistent with the preset checksum value and the inverse value of the calculated checksum CRC32 value is consistent with the inverse value of the preset checksum value, judging that the code of the Boot program is complete.
Because the calculation mode of the CRC (Cyclic Redundancy Check ) 32 value is simple, the check can be completed in a shorter time, and the fault tolerance is high, therefore, the check rate and the fault tolerance can be effectively improved by firstly acquiring the calculated checksum CRC32 value of the corresponding storage section and the inverse value of the calculated checksum CRC32 value according to the checksum starting address and the checksum ending address, and then checking the integrity of the codes of the boot program according to the calculated checksum CRC32 value, the inverse value of the calculated checksum CRC32 value, the preset checksum value and the inverse value of the preset checksum value.
It should be noted that, as those skilled in the art can understand, the related content of how to obtain the calculated checksum CRC32 value and the inverse value of the calculated checksum CRC32 value according to the checksum start address and the checksum end address may be referred to as related content known to those skilled in the art, and will not be described herein.
In some exemplary embodiments, the verifying the integrity of the header structure data of the Boot program according to the preset header structure check value and the inverse value of the preset header structure check value includes:
obtaining a calculated head structure CRC32 value and a calculated head structure CRC32 value according to the starting code address, the valid flag bit, the checksum starting address, the checksum ending address, the preset checksum value and the preset checksum value;
And if the calculated head structure CRC32 value is consistent with the preset head structure check value, and the inverse value of the calculated head structure CRC32 value is consistent with the inverse value of the preset head structure check value, judging that the head structure data of the Boot program is complete.
Obtaining a calculation head structure CRC32 value and a calculation head structure CRC32 value by taking the inverse value according to the initial code address, the valid flag bit, the checksum initial address, the checksum end address, the preset checksum value and the preset checksum value; and checking the integrity of the head structure data of the Boot program according to the calculated head structure CRC32 value, the inverse value of the calculated head structure CRC32 value, the preset head structure check value and the inverse value of the preset head structure check value, so that the check rate and the fault tolerance can be further effectively improved.
It should be noted that, as will be understood by those skilled in the art, regarding how to obtain the calculated header structure CRC32 value and the relevant content of the calculated header structure CRC32 value according to the start code address, the valid flag bit, the checksum start address, the checksum end address, the preset checksum value and the preset checksum value, the relevant content of the calculated header structure CRC32 value is known by those skilled in the art, and will not be described herein.
Based on the same inventive concept, the present invention further provides a vehicle controller, please refer to fig. 7, which is a block structure schematic diagram of the vehicle controller according to an embodiment of the present invention. As shown in fig. 7, the vehicle controller includes a processor 101 and a memory 103, and the memory 103 stores a computer program, which when executed by the processor 101, implements the Boot program self-refresh method described above. Because the vehicle controller provided by the invention and the Boot program self-refreshing method provided by the invention belong to the same inventive concept, the vehicle controller provided by the invention has at least all the beneficial effects of the Boot program self-refreshing method provided by the invention, and specific reference can be made to the related description of the beneficial effects of the Boot program self-refreshing method provided by the invention, and details are not repeated here.
As shown in fig. 7, the vehicle controller further includes a communication interface 102 and a communication bus 104, wherein the processor 101, the communication interface 102, and the memory 103 perform communication with each other through the communication bus 104. The communication bus 104 may be a peripheral component interconnect standard (PERIPHERAL COMPONENT INTERCONNECT, PCI) bus, or an extended industry standard architecture (Extended Industry Standard Architecture, EISA) bus, or the like. The communication bus 104 may be classified as an address bus, a data bus, a control bus, or the like. For ease of illustration, the figures are shown with only one bold line, but not with only one bus or one type of bus. The communication interface 102 is used for communication between the vehicle controller and other devices.
It should be noted that, as those skilled in the art can understand, the processor 101 may be, but is not limited to, an ARM m0+ core chip processor.
The memory 102 is used as a computer readable storage medium for storing a software program, a computer executable program and a module, such as a program instruction/module corresponding to the Boot program self-refresh method provided by the present invention. The processor 101 executes various functional applications of the vehicle controller and data processing by running software programs, instructions and modules stored in the memory 102, i.e., implements the Boot program self-refresh method described above.
The memory 102 may mainly include a memory program area and a memory data area, wherein the memory program area may store an operating system, a Boot program, and an application program required for at least one function; the storage data area may store data created according to the use of the vehicle controller, or the like. In addition, memory 102 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid-state storage device. In some examples, memory 102 may further include memory remotely located relative to processor 101, which may be connected to the vehicle controller via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof. It should be noted that, as will be understood by those skilled in the art, the processor 101 and the program storage area in the memory 102 may be integrally disposed on an ARM chip.
The invention also provides a readable storage medium, wherein the readable storage medium stores a computer program, and the computer program can realize the Boot program self-refreshing method when being executed by a processor. Because the removable storage medium provided by the invention and the Boot program self-refreshing method provided by the invention belong to the same inventive concept, the removable storage medium provided by the invention has at least all the beneficial effects of the Boot program self-refreshing method provided by the invention, and the description of the beneficial effects of the Boot program self-refreshing method provided by the invention can be referred to in detail, and will not be repeated here.
The invention provides a readable storage medium that may take the form of any combination of one or more computer-readable media. The readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium would include the following: an electrical connection having one or more wires, a portable computer hard disk, a hard disk, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
The computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, either in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
The invention also provides a vehicle comprising a vehicle controller as described above or a readable storage medium as described above. Because the vehicle controller or the readable storage medium provided by the invention and the Boot program self-refreshing method provided by the invention belong to the same inventive concept, the vehicle with the vehicle controller or the readable storage medium provided by the invention and the Boot program self-refreshing method provided by the invention also belong to the same inventive concept, so that the vehicle provided by the invention also has all the beneficial effects of the Boot program self-refreshing method provided by the invention, and the description about the beneficial effects of the Boot program self-refreshing method provided by the invention can be referred to in detail, and the details are not repeated here.
In summary, compared with the prior art, the Boot program self-refreshing method, the vehicle controller, the readable storage medium and the vehicle provided by the invention have the following beneficial effects:
The method comprises the steps of firstly copying old-version Boot programs stored in a source Boot storage block into a backup Boot storage block; erasing the old-version Boot program stored in the source Boot storage block, and storing a new-version Boot program into the source Boot storage block; and finally, checking the Boot program stored in the source Boot storage block and/or the backup Boot storage block by adopting a BootRom program stored at the starting address of the ARM chip, and running the Boot program with successful check. Therefore, in the self-refreshing process of the Boot program, the old-version Boot program is copied into the backup Boot storage block, the old-version Boot program is erased from the source Boot storage block, and the new-version Boot program is stored into the source Boot storage block, so that when the new-version Boot program stored in the source Boot storage block is incomplete in the Boot program updating process, the Boot program stored in the backup Boot storage block can be verified by the Boot program after the Boot program is electrified again, and the backup Boot program (namely the Boot program stored in the backup Boot storage block) is operated after the Boot program is verified successfully, so that the controller (such as a vehicle ECU) has refreshing capability all the time, the risk that the program cannot normally operate due to incomplete Boot program, the controller is in a brick form can be effectively reduced, and the after-sale cost of the controller is effectively reduced. In addition, the invention can carry out self-refreshing according to the refreshing flow of the client, and when the Boot program after the downloading appears Bug, the client can finish refreshing the Boot program, thereby improving the after-sale efficiency.
It should be noted that computer program code for carrying out operations of the present invention may be written in one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).
It should be noted that the apparatus and methods disclosed in the embodiments herein may be implemented in other ways. The apparatus embodiments described above are merely illustrative, for example, flow diagrams and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments herein. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions. In addition, the functional modules in the embodiments herein may be integrated together to form a single part, or the modules may exist alone, or two or more modules may be integrated to form a single part.
It should also be noted that the above description is only for the preferred embodiments of the present invention, and not for any limitation of the scope of the present invention, and any changes and modifications made by those skilled in the art based on the above disclosure shall fall within the scope of the present invention. It will be apparent to those skilled in the art that various modifications and variations can be made to the present invention without departing from the spirit or scope of the invention. Thus, the present invention is intended to include such modifications and alterations insofar as they come within the scope of the invention or the equivalents thereof.
Claims (10)
1. The Boot program self-refreshing method is characterized by comprising the following steps of:
copying the old version Boot program stored in the source Boot storage block into the backup Boot storage block according to the acquired Boot program self-refreshing instruction;
erasing the old-version Boot program stored in the source Boot storage block, and storing a new-version Boot program into the source Boot storage block;
After the power is on again, the BootRom program stored at the starting address of the ARM chip is adopted to check the BootRom program stored in the source Bootstorage block and/or the backup Bootstorage block, and the Bootprogram with successful check is operated.
2. The Boot program self-refreshing method according to claim 1, wherein the verifying the Boot program stored in the source Boot memory block and/or the backup Boot memory block comprises:
Checking the Boot program according to the head structure data of the Boot program;
When the old version Boot program stored in the source Boot storage block is copied into the backup Boot storage block, the method further comprises the following steps:
and updating the head structure data of the old version Boot program stored in the backup Boot storage block.
3. The Boot program self-refresh method of claim 2, wherein the header structure data comprises a start code address, a valid flag bit, a checksum start address, a checksum end address, a preset checksum value, an inverse of the preset header structure check value, and an inverse of the preset header structure check value.
4. The Boot program self-refreshing method according to claim 3, wherein the verifying the Boot program according to the header structure data of the Boot program comprises:
checking the validity of the Boot program according to the valid flag bit in the head structure data of the Boot program;
if the validity check is successful, checking the integrity of the code of the Boot program according to the preset checksum value and the inverse value of the preset checksum value;
If the integrity check of the code of the Boot program is successful, checking the integrity of the header structure data of the Boot program according to the preset header structure check value and the inverse value of the preset header structure check value;
And if the integrity check of the head structure data is successful, judging that the Boot program is successful in check.
5. The Boot program self-refreshing method according to claim 4, wherein the verifying the integrity of the code of the Boot program according to the preset checksum value and the inverse value of the preset checksum value comprises:
Acquiring a calculated checksum CRC32 value of a corresponding storage segment and a negation value of the calculated checksum CRC32 value according to the checksum starting address and the checksum ending address;
And if the calculated checksum CRC32 value is consistent with the preset checksum value and the inverse value of the calculated checksum CRC32 value is consistent with the inverse value of the preset checksum value, judging that the code of the Boot program is complete.
6. The Boot program self-refresh method of claim 4, wherein verifying the integrity of the header structure data of the Boot program according to the preset header structure check value and the inverse of the preset header structure check value comprises:
obtaining a calculated head structure CRC32 value and a calculated head structure CRC32 value according to the starting code address, the valid flag bit, the checksum starting address, the checksum ending address, the preset checksum value and the preset checksum value;
And if the calculated head structure CRC32 value is consistent with the preset head structure check value, and the inverse value of the calculated head structure CRC32 value is consistent with the inverse value of the preset head structure check value, judging that the head structure data of the Boot program is complete.
7. The Boot program self-refresh method of claim 1, wherein the Boot program is configured with start address information of the source Boot memory block and the backup Boot memory block, and the Boot program is configured to preferentially check the Boot program stored in the source Boot memory block.
8. A vehicle controller comprising a processor and a memory, the memory having stored thereon a computer program which, when executed by the processor, implements the Boot program self-refresh method of any one of claims 1 to 7.
9. A readable storage medium, wherein a computer program is stored in the readable storage medium, and when the computer program is executed by a processor, the Boot program self-refresh method according to any one of claims 1 to 7 is implemented.
10. A vehicle comprising the vehicle controller of claim 8 or the readable storage medium of claim 9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311749298.1A CN117908917A (en) | 2023-12-19 | 2023-12-19 | Boot program self-refreshing method, vehicle controller, readable storage medium and vehicle |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311749298.1A CN117908917A (en) | 2023-12-19 | 2023-12-19 | Boot program self-refreshing method, vehicle controller, readable storage medium and vehicle |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117908917A true CN117908917A (en) | 2024-04-19 |
Family
ID=90693074
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311749298.1A Pending CN117908917A (en) | 2023-12-19 | 2023-12-19 | Boot program self-refreshing method, vehicle controller, readable storage medium and vehicle |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117908917A (en) |
-
2023
- 2023-12-19 CN CN202311749298.1A patent/CN117908917A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110058873B (en) | Application page updating method, device, equipment and storage medium | |
| CN107077396B (en) | In-vehicle control device, program writing device, program generating device, and method | |
| KR100584338B1 (en) | Method and system for updating software | |
| US20110004871A1 (en) | Embedded electronic device and firmware updating method thereof | |
| CN112416406B (en) | Terminal equipment upgrading method, device, terminal equipment and medium | |
| CN111813428A (en) | Method and device for upgrading terminal firmware, electronic equipment and storage medium | |
| CN112015447B (en) | System updating method and device of electronic equipment, electronic equipment and storage medium | |
| CN113504918A (en) | Equipment tree configuration optimization method and device, computer equipment and storage medium | |
| CN108604207B (en) | System and method for hardware independent memory storage | |
| CN114780019A (en) | Electronic device management method and device, electronic device and storage medium | |
| US9996296B2 (en) | Electronic control unit and method for rewriting data | |
| JP2019016086A (en) | Automobile electronic control device | |
| WO2018142749A1 (en) | Control device, program updating method, and computer program | |
| US20210349855A1 (en) | Method of data structuring for difference between old and new data and device thereof | |
| CN117908917A (en) | Boot program self-refreshing method, vehicle controller, readable storage medium and vehicle | |
| US10732887B2 (en) | Cable modem and operating method thereof | |
| US20220391192A1 (en) | Ota master, center, system, method, non-transitory storage medium, and vehicle | |
| CN108491160B (en) | Data writing method and device | |
| US20220244946A1 (en) | Ota master, update control method, non-transitory storage medium, and vehicle | |
| US20220035620A1 (en) | Software update device, update control method, non-transitory storage medium, and server | |
| CN113703801A (en) | Vehicle-mounted terminal firmware upgrading method and electronic device | |
| CN115061713A (en) | Method and device for upgrading electronic equipment | |
| CN115048154B (en) | Vehicle-mounted configuration information management method, device, system and storage medium | |
| US20220391193A1 (en) | Ota master, system, method, non-transitory storage medium, and vehicle | |
| KR102452400B1 (en) | Difference update method for vehicullr control unit and difference update roll back method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication |