CN116594661B - Singlechip upgrading method for ensuring matching of firmware and engineering in compiling stage - Google Patents
Singlechip upgrading method for ensuring matching of firmware and engineering in compiling stage Download PDFInfo
- Publication number
- CN116594661B CN116594661B CN202310885427.3A CN202310885427A CN116594661B CN 116594661 B CN116594661 B CN 116594661B CN 202310885427 A CN202310885427 A CN 202310885427A CN 116594661 B CN116594661 B CN 116594661B
- Authority
- CN
- China
- Prior art keywords
- file header
- update
- area
- execution
- firmware
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 37
- 238000012795 verification Methods 0.000 claims abstract description 12
- 238000013524 data verification Methods 0.000 claims abstract description 7
- 230000008569 process Effects 0.000 claims description 10
- 230000009191 jumping Effects 0.000 claims description 6
- 238000000638 solvent extraction Methods 0.000 claims description 2
- 238000005192 partition Methods 0.000 abstract description 3
- 238000013461 design Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 9
- 238000011161 development Methods 0.000 description 6
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000035515 penetration Effects 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000005856 abnormality Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 238000007429 general method Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000007789 sealing Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Abstract
The application relates to a singlechip upgrading method for ensuring the matching of firmware and engineering in a compiling stage, which comprises the following steps: a step of self-defining on-chip resource division; inquiring whether an update mark value at the Flash update file header is an update mark or not, if so, copying the update area firmware to an execution area according to the file length in the update file header, calculating the data verification of the execution area, and judging whether the data verification is matched with the verification value in the update file header or not, and then performing corresponding operation; and receiving the updated file header, matching the equipment information in the received file header with the file header of the execution area, if the matching is successful, receiving the rest part of the updated firmware and writing the rest part of the updated firmware into the updated area, and checking whether the data of the updated area is matched with the check value in the previously received updated file header or not and then carrying out corresponding operation. The application completely and autonomously controls the use of the on-chip memory of the singlechip, clearly uses the memory space in a partition, completely controls the program during compiling and linking and running, and precisely grasps the memory address of each variable clearly.
Description
Technical Field
The application relates to the technical field of singlechip firmware upgrading, in particular to a singlechip upgrading method for ensuring matching of firmware and engineering in a compiling stage.
Background
In many single-chip microcomputer product designs, on-line upgrading functions are required to be designed in consideration of the convenience of product software updating. The general method is Uboot+App, uboot is the first program executed by power-on and used for copying the upgrade program to the running address, and App is the product application program. The traditional upgrade flow design basically takes Uboot and App as two programming, the interaction between the Uboot and the App is very little, only some mark information is needed, and the Uboot and the App are generally read and written through Flash on a chip. Because Flash on a chip is paged, data writing must be performed after the whole page is erased, so that updating of a few bytes of flag data must be performed after the whole page is erased, and the efficiency is low. And the general design is that the update address of the App is fixed in advance, and the flexibility is poor. One of the most fatal problems is that many products are simply designed for upgrading functions. The firmware is usually only received in the App, then written into the update address of Flash, then the singlechip is reset, and in Uboot, the firmware of the update address is copied to the execution address, and then the execution is reset. The whole process is simple and rough, the verification function of product information is not available, once the updated firmware is selected to have errors, the function is abnormal due to light weight, and the product is halted and cannot be used due to heavy weight. While some designs solve this problem by adding some other information to the firmware by other tools after compiling the program, this breaks the files obtained after compiling the native project, and is inconvenient to manage, and does not match the generated firmware with the native project. In addition, in many single-chip software designs, depending on some integrated development environments, such as Keil, and the like, a development tool is used for default engineering configuration, so that the stack space size is fixed by a single-chip starting file and is close to a global data area, once the stack space size is not designed enough and the code function call level is too many or local variables are too large, a stack pointer can penetrate through the global data area to cross the boundary, so that serious problems of memory coverage are caused, and the problems are difficult to find and difficult to find.
It should be noted that the information disclosed in the above background section is only for enhancing understanding of the background of the present disclosure and thus may include information that does not constitute prior art known to those of ordinary skill in the art.
Disclosure of Invention
The application aims to overcome the defects of the prior art, provides a singlechip upgrading method for ensuring the matching of firmware and engineering in a compiling stage, and solves the problems in the prior art.
The aim of the application is achieved by the following technical scheme: a singlechip upgrade method for ensuring matching of firmware and engineering in a compiling stage, the upgrade method comprising:
the method comprises the following steps of self-defining on-chip resource partitioning: dividing a memory on the singlechip into a system parameter area, an announcement parameter area and a shared area in sequence, and dividing Flash storage on the singlechip into a Uboot, an execution file header, an execution area, an update file header, an update area, a backup file header and a backup area in sequence;
uboot execution: inquiring whether an update mark value at the Flash update file header is an update mark, if so, copying the update area firmware to the execution area according to the file length in the update file header after erasing the execution area data, calculating the execution area data for verification, judging whether the update area data is matched with the verification value in the update file header, and performing corresponding operation according to a judgment result;
app performs the steps of: and receiving the updated file header, matching the equipment information in the received file header with the file header of the execution area, if the matching is successful, receiving the rest part of the updated firmware and writing the rest part of the updated firmware into the updated area, checking whether the data of the updated area is matched with the check value in the previously received updated file header, and performing corresponding operation according to the check result.
The judging whether the check value in the updated file header is matched with the check value or not, and the corresponding operation according to the judging result specifically comprises the following steps:
if the data verification of the execution area is matched with the verification value in the update file header, changing the update mark in the update file header into a programming mark, writing the content of the update file header into the execution file header, erasing the update file header, and jumping to the execution area to start to execute the updated App firmware program;
if the data verification of the execution area is not matched with the verification value in the updated file header, which indicates that an error occurs in the process of writing the execution area, the content of the execution file header is erased, then the operation is stopped, and the next operation is waited.
In the Uboot execution step, if the update mark of the Flash update file header is not the update mark, which indicates that the App program does not perform firmware upgrade operation, judging whether the Uboot execution mark in the notification parameter area is set, and if so, waiting for firmware upgrade operation;
if the Uboot execution upgrading mark in the notification parameter area is not set, judging whether the updating mark in the execution file header is a programming mark, if so, jumping to the execution area to execute the App program, otherwise, indicating that the data content of the execution area is wrong or the App program is not programmed, and waiting for firmware upgrading operation.
The App execution step specifically includes:
if the data of the update area is matched with the check value in the update file header received before, the operation of writing in the update area is free from errors, the update mark in the update file header is set as an update mark, the changed file header is written in the Flash update file header, finally whether the check value of the Flash update file header is matched with the written file header is checked, if so, the writing is free from errors, and then the singlechip is reset to enter Uboot, so that the update operation is completed;
if the data of the update area does not match the check value in the update file header received before, the upgrade is terminated and an error is returned.
In the step of dividing the self-defined on-chip resources, a system parameter area is set by a Uboot program and is used for recording the division condition of a Flash storage space for an App program to use; the Uboot program runs on the Uboot, and the App program runs on the execution area;
the notice parameter area is used for parameter storage of the App program transmitted to the Uboot program, resetting is carried out after the App program is set, and the Uboot program directly obtains and uses the notice parameter area;
the public area comprises a global data area and a stack area, is used for supporting the environment of independent operation of the Uboot program and the App program, and adjusts a stack pointer operated by the program to the maximum address of the internal memory on the singlechip.
The App program comprises an execution file header address, an execution area size, an update file header address, an update area size, a backup file header address, a backup area address and a backup area size.
When the App program is compiled and then written into a product, the running firmware is distributed in an execution file header part and an execution area part of the storage space; the execution file header part is used for identifying the attribute of the running program in the current execution area and the corresponding product hardware attribute information; the execution area part is used for running the APP program; meanwhile, the updated firmware file generated after the program is compiled is also divided into an execution file header part and an execution area part, wherein the execution file header part is completely consistent with the execution file header of the program running at the moment of the current product.
The application has the following advantages:
1. the memory on the single chip microcomputer chip is completely and autonomously controlled, the memory space is clearly used by the partition, and the Uboot program and the product App application program are completely controlled during compiling, linking and running, so that the memory address of each variable can be clearly mastered accurately.
2. And (3) adjusting and optimizing the use of the stack space, lifting the stack pointer to the maximum address of the on-chip memory, utilizing the memory space to the maximum extent, and avoiding memory waste. Meanwhile, the stack pointer is furthest far away from the global data area of the program operation, so that the problem of memory coverage caused by penetration of the stack pointer to the global data in the process of the program operation is furthest avoided, and the safety of the program operation is ensured.
3. The system parameters and the notification parameters of the memory division are shared by Uboot and App, so that the difficulty of communication between Uboot and App programs is avoided. Meanwhile, the memory space is used for data reading and writing, so that the speed is high and the efficiency is high. The awkward operation of erasing and writing using the Flash space is avoided, and the waste of the Flash storage space is reduced.
4. The division of the Flash storage area of the product is completely determined by Uboot program control, the system parameters are used for informing the App program, the App program does not need to know the firmware upgrading backup information such as the address of the update area, the address of the backup area and the like in advance, the unified design can be completely realized, and the design flexibility is improved. Different types of single-chip microcomputer basically only need to modify the memory area division of Uboot, and the App program can update the protocol and mode uniformly, so that the method is simple and convenient.
5. The App application program generates corresponding file matching information in the compiling and linking process, and is used for unifying the original engineering codes, the product hardware and the updated firmware, and the consistency of the original engineering codes, the product hardware and the updated firmware is maintained. Therefore, the current running program can only upgrade the firmware compiled by the original engineering code of the current program, the sealing performance and the safety of the product software are improved, and the influence caused by operation errors is avoided. In the upgrading process, the consistency of the firmware is immediately identified, and the firmware is not required to be identified by other means after the transmission of the upgraded firmware is completed.
Drawings
FIG. 1 is a schematic diagram of the structure of the present application;
FIG. 2 is a schematic flow chart of Uboot program execution;
FIG. 3 is a flow chart of an App program execution;
fig. 4 is a memory distribution and Flash storage space distribution diagram of a single chip microcomputer in an example.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. The components of the embodiments of the present application generally described and illustrated in the figures herein may be arranged and designed in a wide variety of different configurations. Accordingly, the following detailed description of the embodiments of the application, as presented in conjunction with the accompanying drawings, is not intended to limit the scope of the application as claimed, but is merely representative of selected embodiments of the application. All other embodiments, which can be made by a person skilled in the art without making any inventive effort, are intended to be within the scope of the present application. The application is further described below with reference to the accompanying drawings.
The application relates to a singlechip upgrading method for ensuring matching of firmware and engineering in a compiling stage, which aims to solve the problem of inconvenience and unsafe of flow design of the existing singlechip software upgrading system. The data interaction between the Uboot program and the App program is more convenient when the software is updated, flash read-write operation of some mark data is avoided, and the whole page of Flash resources are not wasted due to storage of some mark data. Meanwhile, the matching problem of the upgrading firmware and the native software engineering codes is solved, so that the firmware compiled by the current software engineering can only be upgraded into a product running the current software engineering program. During the upgrading process, the error of the firmware selection is carelessly taken, and even if the single chip microcomputer with the same type is used, products with different versions with the same type can also judge the firmware abnormality and reject the upgrading. The consistency of the software engineering code, the product and the updated firmware is completely achieved. And the design of the software running stack space is optimized, and the on-chip memory of the singlechip is utilized to the greatest extent, so that the problem of memory coverage caused by penetration of a stack pointer into a global data area is avoided to the greatest extent.
As shown in fig. 1, the following are specifically included:
the use of the on-chip memory of the singlechip is completely customized, and the on-chip memory is divided into a system parameter area, an announcement parameter area and a public area. The system parameter area is used for recording the division condition of the Flash storage space and is set by the Uboot program for the App program to use. The method comprises the steps of executing header file address, executing area size, updating header file address, updating area address and the like of an App program. The notice parameter area is used for storing parameters transferred to the Uboot program by the App program, and the Uboot program can be directly obtained and used after the App program is set and then reset to enter the Uboot. The public area is used for the environment support of the independent running of the Uboot program and the App program, and comprises a global data area, a stack area and the like. And simultaneously, the stack pointer of the program operation is adjusted to the maximum address of the on-chip memory of the singlechip, and the stack growth mode is gradually increased downwards in the process of the program operation, so that the on-chip memory space is utilized to the maximum extent, and meanwhile, the stack pointer is far away from the global data area of the program operation, and the safety of the program operation is ensured.
As shown in fig. 2, the flow of execution of the Uboot program is as follows:
the singlechip is electrified, and whether the update mark value at the head of the Flash update file is an update mark or not is firstly inquired. If the update flag is set, the execution area data is first erased, and then the update area firmware data is copied to the execution area according to the file length in the update file header. After copying is completed, calculating the data verification of the execution area, and judging whether the verification value in the file header is matched with the verification value in the updated file header. If the content of the updated file header is matched, the updated mark in the updated file header is changed into a programming mark, and then the content of the updated file header is written into the execution file header. And erasing the updated file header, and finally jumping to the execution area to start to execute the updated App firmware program. If the check value of the execution area data and the update file header is not matched, the error occurs in the process of writing the execution area, the content of the execution file header is erased, then the execution file is exited, and all the operations are performed again when the next power-on is performed.
If the update flag value of the Flash update file header is not the update flag, the App program is represented as not carrying out firmware upgrading operation. Then judging whether the Uboot execution flag in the notification parameter area is set, and if so, waiting for firmware upgrading operation. The flag mainly informs the Uboot that a firmware upgrade operation needs to be performed in the Uboot. The method is mainly used for singlechip type products with limited Flash storage resources and cannot divide a plurality of partitions, so that actions of receiving and upgrading firmware are executed in Uboot and are directly written into an execution area.
If the Uboot execution upgrading mark in the notification parameter area is not set, judging whether the updating mark in the execution file header is a programming mark, and if so, jumping to the execution area to execute the App program. Otherwise, the data content of the representative execution area is wrong, or the App program is not programmed by the current product, waiting for firmware upgrading operation.
As shown in fig. 3, the flow of App program execution is as follows:
and after the App program in the execution area runs, waiting for an upgrade instruction. When upgrading, the update file header is received first. Subsequently, the received data such as the device name, model code, hardware version number and the like in the file header and the execution area file header are matched. If both matches are successful, the current update firmware file is the firmware compiled by the native engineering of the currently running program, thus supporting upgrades. Otherwise, returning error information and terminating the upgrade operation.
If the file header information matches, the other parts of the upgraded firmware continue to be received and written to the update section. After the receiving is completed, checking whether the data of the update area is matched with the check value in the update file header received before. If the file header is matched, the operation of writing the update area is not wrong, the update flag value in the update file header is set as an update flag, and then the changed file header is written into the Flash update file header. And finally, checking whether the check value of the Flash updated file header is matched with the written file header, if so, indicating that writing is error-free, resetting the singlechip to enter Uboot, and finishing the updating operation.
When the application program is compiled and then written into the product, the running firmware is distributed in two parts of the storage space. The first part is an execution file header part and is used for identifying the attribute of the running program in the current execution area, the corresponding product hardware attribute and other information. The other part is an execution area part and is the most main part of the App program. Meanwhile, after the program is compiled, the generated updated firmware file is divided into two parts, wherein the file header part is completely consistent with the execution file header of the program running at the moment of the current product.
The key point of the application is mainly how to fix the variable definition in the program code and the variable use in the running process to a specific memory address, and how to fix and reflect some characteristic information in the program code to a designated position of the firmware generated after compiling and linking, so that the generated firmware file corresponds to the engineering code. The characteristics of memory redirection and firmware scattered loading operation of the corresponding compiling tool chain of the singlechip are mainly needed to be used for completing the functions. The following is demonstrated by STM32 Cortex M3, M4 series core singlechip, the singlechip uses STM32F103VE chip, the chip has 64KB on-chip memory space, 512KB on-chip Flash memory space. The development environment uses Keil to integrate the development environment, the corresponding compiling tool is armcc, and the linking tool is armlink.
First, in the Uboot code, a system parameter structure variable is defined, and a member variable value is initialized according to the division of Flash storage space in fig. 4, a link attribute is set using __ attribute () when definition, a "used" attribute key is used, the compiler is prevented from optimizing deletion of the variable, and a link symbol ". Sysparam" is designated by section (". Sysparam").
Then, a scattered loading script file (sct file) of the Uboot program is created and used by a Keil development tool, and the memory use condition and the Flash storage space use condition of the firmware generated after compiling and linking are specified. The method comprises the steps of directing a symbol part of sysparam to a system parameter memory address 20000000H, directing a symbol part of STACK to a singlechip maximum memory address 20010000H, directing other variable parts of a program of ANY (+ RW+ZI) to a memory address 20000100H, and directing a program execution part of ANY (+ RO) to a Flash address 08000000H.
Then, in the App code, the advertisement parameter structure body variable and the file header structure body variable are defined, and the "used" attribute key is also used to avoid the compiler from optimizing deletion. The notification parameter variable link symbol is designated as ". Notify", the file header variable link symbol is designated as ". File_head", and each member variable value including a device name, a model code, a hardware version number, etc. is initialized according to the product hardware information when the file header variable is defined.
And finally, creating a scattered loading script file (sct file for Keil development tools) of the App program, and designating the memory use condition and Flash storage space use condition of the firmware generated after compiling and linking. The method comprises the steps of directing a symbol part of 'notify' to an announcement parameter memory address 20000080H, directing a symbol part of 'STACK' to a maximum memory address 20010000H of a singlechip, directing other variable parts of 'ANY (+ RW+ZI)' in a program to a memory address 20000100H, directing a symbol part of 'file_head' to a Flash execution file header address 08004000H, and directing other running parts of the program 'ANY (+ RO)' to a Flash execution region address 08004800H. The generated firmware FILE is divided into two parts, one part is a FILE header, the corresponding FILE name is file_head, and the data content is the data initialized by the FILE header structure body variable. The other part is the other part of the software program, and the corresponding file name is APP_ROM.
As shown in fig. 4, after the Uboot program is compiled and programmed, the Uboot program runs at addresses 08000000H-08004000H in the Flash storage space, the running memory is located at addresses 20000100H-20010000H in the memory space, the Uboot sets up system parameters at 20000000H in the memory address for the App program to use, and at the same time receives notification parameters set by the App program at the address 20000080H, and executes processing of corresponding functions.
After the App program is programmed, the App program runs at two addresses of 08004000H-08004800H (execution file header) and 08004800H-0802C 800H (execution area) of the Flash storage space, the running memory is located at the addresses of the memory spaces 20000100H-20010000H, and the App informs the Uboot of which operations should be executed by setting notification parameters at the addresses of the memory 20000080H. The firmware compiled and generated by the App program is provided with two FILEs, namely a file_HEAD FILE and an APP_ROM, wherein the file_HEAD FILE corresponds to an 'execution FILE header' part of the Flash space, and the APP_ROM FILE corresponds to an 'execution area' part of the Flash space. When the singlechip is upgraded, firstly, a file_head FILE is issued, and an App program judges whether the received file_head FILE is matched with information such as a device name, a model code, a hardware version number and the like in an execution FILE header of a current running program. If the FILE is matched, the file_HEAD FILE issued is compiled for the original engineering of the current running program, and the upgrade is supported. Otherwise, the upgrade operation is refused and terminated. In actual operation, file_head and app_rom may be synthesized into one FILE for convenience of FILE management. The content of the update header may also be utilized to despread and perfect the upgrade function, for example, the type of the upgrade file may be specified by a file type parameter in the header, so as to support other data updates. The function of updating the design patch can also be realized by comparing the APP_ROM file.
The foregoing is merely a preferred embodiment of the application, and it is to be understood that the application is not limited to the form disclosed herein but is not to be construed as excluding other embodiments, but is capable of numerous other combinations, modifications and environments and is capable of modifications within the scope of the inventive concept, either as taught or as a matter of routine skill or knowledge in the relevant art. And that modifications and variations which do not depart from the spirit and scope of the application are intended to be within the scope of the appended claims.
Claims (6)
1. A singlechip upgrading method for ensuring matching of firmware and engineering in compiling stage is characterized in that: the upgrading method comprises the following steps:
the method comprises the following steps of self-defining on-chip resource partitioning: dividing a memory on the singlechip into a system parameter area, an announcement parameter area and a public area in sequence, and dividing Flash storage on the singlechip into a Uboot, an execution file header, an execution area, an update file header, an update area, a backup file header and a backup area in sequence;
uboot execution: inquiring whether an update mark value at the Flash update file header is an update mark, if so, copying the update area firmware to the execution area according to the file length in the update file header after erasing the execution area data, calculating the execution area data for verification, judging whether the update area data is matched with the verification value in the update file header, and performing corresponding operation according to a judgment result;
app performs the steps of: receiving an update file header, matching the equipment information in the received file header with an execution area file header, if the matching is successful, receiving the rest part of the update firmware and writing the rest part of the update firmware into an update area, checking whether the data of the update area is matched with a check value in the update file header received before, and performing corresponding operation according to a check result;
in the step of dividing the self-defined on-chip resources, a system parameter area is set by a Uboot program and is used for recording the division condition of a Flash storage space for an App program to use; the Uboot program runs on the Uboot, and the App program runs on the execution area;
the notice parameter area is used for parameter storage of the App program transmitted to the Uboot program, resetting is carried out after the App program is set, and the Uboot program directly obtains and uses the notice parameter area;
the public area comprises a global data area and a stack area, is used for supporting the environment of independent operation of the Uboot program and the App program, and adjusts a stack pointer operated by the program to the maximum address of the internal memory on the singlechip.
2. The method for upgrading a single-chip microcomputer for ensuring matching of firmware and engineering at a compiling stage according to claim 1, wherein the method comprises the following steps: the judging whether the check value in the updated file header is matched with the check value or not, and the corresponding operation according to the judging result specifically comprises the following steps:
if the data verification of the execution area is matched with the verification value in the update file header, changing the update mark in the update file header into a programming mark, writing the content of the update file header into the execution file header, erasing the update file header, and jumping to the execution area to start to execute the updated App firmware program;
if the data verification of the execution area is not matched with the verification value in the updated file header, which indicates that an error occurs in the process of writing the execution area, the content of the execution file header is erased, then the operation is stopped, and the next operation is waited.
3. The method for upgrading a single-chip microcomputer for ensuring matching of firmware and engineering at a compiling stage according to claim 1, wherein the method comprises the following steps: in the Uboot execution step, if the update mark of the Flash update file header is not the update mark, which indicates that the App program does not perform firmware upgrade operation, judging whether the Uboot execution mark in the notification parameter area is set, and if so, waiting for firmware upgrade operation;
if the Uboot execution upgrading mark in the notification parameter area is not set, judging whether the updating mark in the execution file header is a programming mark, if so, jumping to the execution area to execute the App program, otherwise, indicating that the data content of the execution area is wrong or the App program is not programmed, and waiting for firmware upgrading operation.
4. The method for upgrading a single-chip microcomputer for ensuring matching of firmware and engineering at a compiling stage according to claim 1, wherein the method comprises the following steps: the App execution step specifically includes:
if the data of the update area is matched with the check value in the update file header received before, the operation of writing in the update area is free from errors, the update mark in the update file header is set as an update mark, the changed file header is written in the Flash update file header, finally whether the check value of the Flash update file header is matched with the written file header is checked, if so, the writing is free from errors, and then the singlechip is reset to enter Uboot, so that the update operation is completed;
if the data of the update area does not match the check value in the update file header received before, the upgrade is terminated and an error is returned.
5. The method for upgrading a single-chip microcomputer for ensuring matching of firmware and engineering at a compiling stage according to claim 1, wherein the method comprises the following steps: the App program comprises an execution file header address, an execution area size, an update file header address, an update area size, a backup file header address, a backup area address and a backup area size.
6. A method for upgrading a single-chip microcomputer for ensuring matching of firmware and engineering in a compiling stage according to claim 3, wherein the method comprises the following steps: when the App program is compiled and then written into a product, the running firmware is distributed in an execution file header part and an execution area part of the storage space; the execution file header part is used for identifying the attribute of the running program in the current execution area and the corresponding product hardware attribute information; the execution area part is used for running the APP program; meanwhile, the updated firmware file generated after the program is compiled is also divided into an execution file header part and an execution area part, wherein the execution file header part is completely consistent with the execution file header of the program running at the moment of the current product.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310885427.3A CN116594661B (en) | 2023-07-19 | 2023-07-19 | Singlechip upgrading method for ensuring matching of firmware and engineering in compiling stage |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310885427.3A CN116594661B (en) | 2023-07-19 | 2023-07-19 | Singlechip upgrading method for ensuring matching of firmware and engineering in compiling stage |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116594661A CN116594661A (en) | 2023-08-15 |
| CN116594661B true CN116594661B (en) | 2023-09-19 |
Family
ID=87594178
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310885427.3A Active CN116594661B (en) | 2023-07-19 | 2023-07-19 | Singlechip upgrading method for ensuring matching of firmware and engineering in compiling stage |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116594661B (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104581397A (en) * | 2014-12-29 | 2015-04-29 | 四达时代通讯网络技术有限公司 | System upgrade method and device for android set-top box |
| CN109240730A (en) * | 2018-08-29 | 2019-01-18 | 武汉光迅科技股份有限公司 | A kind of single-chip microcontroller online upgrading method and system |
| CN110096294A (en) * | 2019-05-07 | 2019-08-06 | 柏科智能(厦门)科技有限公司 | It is a kind of can break-point radio upgrade MCU application program method |
| CN111309364A (en) * | 2020-05-11 | 2020-06-19 | 深圳市科信通信技术股份有限公司 | Chip program upgrading method and device and storage medium |
| CN114780127A (en) * | 2022-05-09 | 2022-07-22 | 乐鑫信息科技（上海）股份有限公司 | Embedded equipment firmware updating method, embedded equipment and development end equipment |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| TWI497415B (en) * | 2013-06-21 | 2015-08-21 | Wistron Neweb Corp | Methods for upgrading firmware and apparatuses using the same |
-
2023
- 2023-07-19 CN CN202310885427.3A patent/CN116594661B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104581397A (en) * | 2014-12-29 | 2015-04-29 | 四达时代通讯网络技术有限公司 | System upgrade method and device for android set-top box |
| CN109240730A (en) * | 2018-08-29 | 2019-01-18 | 武汉光迅科技股份有限公司 | A kind of single-chip microcontroller online upgrading method and system |
| CN110096294A (en) * | 2019-05-07 | 2019-08-06 | 柏科智能(厦门)科技有限公司 | It is a kind of can break-point radio upgrade MCU application program method |
| CN111309364A (en) * | 2020-05-11 | 2020-06-19 | 深圳市科信通信技术股份有限公司 | Chip program upgrading method and device and storage medium |
| CN114780127A (en) * | 2022-05-09 | 2022-07-22 | 乐鑫信息科技（上海）股份有限公司 | Embedded equipment firmware updating method, embedded equipment and development end equipment |
Non-Patent Citations (2)
| Title |
|---|
| Remap-Based Inter-Partition Copy for Arrayed Solid-State Drives;Kyuhwa Han 等;《IEEE Transactions on Computers》;第71卷(第7期);第1640-1654页 * |
| 基于串口Ymodem和远程FTP固件升级方法研究;李苑 等;《电子测量技术》;第42卷(第13期);第132-136页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116594661A (en) | 2023-08-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109240730B (en) | Singlechip online upgrading method and system | |
| WO2021115477A1 (en) | Program upgrade method and apparatus, electronic device and storage medium | |
| WO2022007656A1 (en) | Bootloader software updating method and apparatus, embedded controller, and storage medium | |
| CN110045991B (en) | RAID configuration method and device of server, computer equipment and storage medium | |
| CN105320554A (en) | Program updating method as well as client and system for program updating | |
| CN111240720A (en) | Boot program upgrading method and device and storage medium | |
| US20030130980A1 (en) | Efficient configuration data migration technique | |
| CN110633091A (en) | Electronic module and software wireless upgrading method thereof | |
| CN113741944A (en) | Machine program system with upgrading function, upgrading method and application | |
| CN113110860A (en) | Remote software updating method for embedded terminal | |
| CN115220758B (en) | Method for on-line upgrading of single chip microcomputer firmware | |
| CN110750280A (en) | Application upgrading method and system based on Android platform and storage medium | |
| CN112068881A (en) | Database upgrading method based on data chain | |
| CN108874422B (en) | Software online upgrading method for refrigerator electric control board, refrigerator electric control board and refrigerator | |
| CN116594661B (en) | Singlechip upgrading method for ensuring matching of firmware and engineering in compiling stage | |
| CN109947407B (en) | Data acquisition method and device | |
| CN116643761A (en) | Customized mirror image manufacturing and deploying method, device, terminal and medium | |
| CN116028084A (en) | Cross-version hot upgrading method, system and terminal based on OpenStack cloud platform | |
| CN115334358A (en) | Automatic software modification method for convergence gateway and storage medium | |
| CN109669699B (en) | Application program distribution method, wireless controller and wireless access point | |
| CN113157329A (en) | Method, system, server and storage medium for starting application | |
| KR100316584B1 (en) | Flash Memory To Share With Booting And Main Operation Program In System And Upgrade Method In That Memory | |
| KR100617796B1 (en) | Mobile terminal equipment capable of upgrading a wireless firmware and method thereof | |
| KR20060015969A (en) | Electronic apparatus and program update method of thereof | |
| CN114995962B (en) | Method for loading emergency patches by initializing container |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |