Program upgrading method and device, storage medium and electronic device

Abstract

The present application discloses a program upgrade method and device, storage medium, and electronic device. Relating to the field of computer technology, the method comprises: receiving an upgrade file via a first program in a target system, wherein the upgrade file is used to upgrade a second program in the target system; parsing and reading the upgrade file via the first program to obtain code data corresponding to the upgrade file; and upgrading the second program in the target system based on the code data corresponding to the upgrade file. This application solves the problem in related technologies of requiring an emulator to be connected to update an application in a processor, resulting in relatively low application update efficiency.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a program upgrading method and device, a storage medium, and an electronic device. Background Art

[0002] For DSP (Digital Signal Processor) embedded systems that have been put into use, when the application code needs to be changed or further improved and upgraded according to actual conditions, the current solution is to connect an emulator and use simulation software to enter the simulation to program the DSP chip's FLASH. This process is cumbersome and time-consuming, and there is a problem of low application update efficiency.

[0003] With regard to the problem in related technologies that the application program in the processor needs to be updated by connecting to an emulator, resulting in relatively low updating efficiency of the application program, no effective solution has been proposed so far. Summary of the Invention

[0004] The main purpose of this application is to provide a program upgrade method and device, storage medium and electronic device to solve the problem in related technologies that the application in the processor needs to be updated by connecting to an emulator, resulting in relatively low update efficiency of the application.

[0005] To achieve the above objectives, according to one aspect of the present application, a program upgrade method is provided. The method comprises: receiving an upgrade file via a first program in a target system, wherein the upgrade file is used to upgrade a second program in the target system; parsing and reading the upgrade file via the first program to obtain code data corresponding to the upgrade file; and upgrading the second program in the target system based on the code data corresponding to the upgrade file.

[0006] Furthermore, upgrading the second program in the target system based on the code data corresponding to the upgrade file includes: reading the current line of code data in the upgrade file, and if the data type corresponding to the current line of code data is a preset first value, obtaining the starting address from the current line of code data, determining the sector corresponding to the starting address as the current sector, and erasing the current sector, wherein the starting address is the flag address of the current sector storing the second program; reading the next line of code data in the upgrade file, and if the data type corresponding to the next line of code data is a preset second value, obtaining the offset address from the next line of code data; determining the target address based on the offset address and the starting address, and burning the next line of code data to the target address to upgrade the second program.

[0007] Furthermore, burning the next line of code data to the target address includes: determining whether the target address is within the current sector to obtain a first determination result; if the first determination result indicates that the target address is within the current sector, burning the next line of code data to the target address.

[0008] Furthermore, after determining whether the target address is within the current sector and obtaining a first judgment result, the method further includes: if the first judgment result indicates that the target address is not within the current sector, setting an erase flag to a preset third value; when the erase flag is set to the preset third value, updating the current sector to a sector corresponding to the target address, and performing an erasing process on the current sector; after erasing the current sector, burning the next line of code data to the target address.

[0009] Furthermore, burning the next line of code data to the target address to upgrade the second program includes: after burning the next line of code data to the target address, repeatedly executing the step of reading the next line of code data in the upgrade file until the data type corresponding to the next line of code data is a preset fourth value, then determining that the upgrade processing of the second program by the upgrade file has been completed.

[0010] Furthermore, after the second program in the target system is upgraded based on the code data corresponding to the upgrade file, the method further includes: determining whether there is a next upgrade file to obtain a second determination result; if the second determination result indicates that the next upgrade file exists, the second program in the target system is upgraded based on the next upgrade file until there is no next upgrade file; if the second determination result indicates that the next upgrade file does not exist, a target signal is triggered, wherein the target signal is used to indicate that the upgrade process for the second program has been completed.

[0011] Furthermore, after receiving the upgrade file through the first program in the target system, the method also includes: storing the upgrade file in a receiving cache area; determining whether there is an error in the upgrade file in the receiving cache area; if there is an error in the upgrade file in the receiving cache area, resetting the receiving cache area and re-receiving the upgrade file.

[0012] Furthermore, before upgrading the second program in the target system based on the code data corresponding to the upgrade file, the method also includes: reading the upgrade file from the receiving buffer through the first program; when reading the upgrade file, determining whether there is an overflow in the receiving buffer; if there is an overflow in the receiving buffer, resetting the receiving buffer and re-receiving the upgrade file.

[0013] Furthermore, before receiving the upgrade file through the first program in the target system, the method also includes: generating an initial upgrade file based on the functional information to be upgraded through the target host computer; judging whether the initial upgrade file needs to be split based on the target threshold through the target host computer; if the initial upgrade file needs to be split, splitting the initial upgrade file based on the target threshold through the target host computer to obtain multiple upgrade files; and transmitting each upgrade file to the first program through the target host computer.

[0014] Furthermore, before receiving the upgrade file through the first program in the target system, the method also includes: starting the boot loader after the target system receives a power-on signal; starting the first program through the boot loader, and establishing a communication mechanism between the first program and the target host computer so that the first program can receive the upgrade file.

[0015] Furthermore, upgrading the second program in the target system based on the code data corresponding to the upgrade file includes: determining whether the frame header mark corresponding to the upgrade file is a preset character; and when the frame header mark is the preset character, upgrading the second program in the target system based on the code data corresponding to the upgrade file.

[0016] To achieve the above objectives, according to another aspect of the present application, a program upgrade system is provided. The system includes: a target host computer, wherein the target host computer is configured to generate an upgrade file and transfer the upgrade file to a first program; and a first program, wherein the first program upgrades a second program in the target system based on the upgrade file.

[0017] To achieve the above-mentioned objectives, according to another aspect of the present application, a program upgrade device is provided. The device comprises: a receiving unit configured to receive an upgrade file via a first program in a target system, wherein the upgrade file is used to upgrade a second program in the target system; a processing unit configured to parse and read the upgrade file via the first program to obtain code data corresponding to the upgrade file; and a first upgrade unit configured to perform upgrade processing on the second program in the target system based on the code data corresponding to the upgrade file.

[0018] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned program upgrade methods when executing the computer program.

[0019] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of the upgrade method of any of the above programs are implemented.

[0020] In an embodiment of the present application, the following steps are adopted: an upgrade file is received through a first program in a target system, wherein the upgrade file is used to upgrade a second program in the target system; the upgrade file is parsed and read through the first program to obtain code data corresponding to the upgrade file; and the second program in the target system is upgraded based on the code data corresponding to the upgrade file, thereby solving the technical problem in related technologies of requiring the application program in the processor to be updated by connecting an emulator, resulting in relatively low update efficiency of the application program.

[0021] In this solution, the first program set in the target system is used to receive the upgrade file, and the first program eliminates the dependence on the dedicated emulator. The first program parses and reads the upgrade file to obtain the corresponding code data. After extracting the code data of the upgrade file, the first program burns the read code data to the corresponding location to implement the upgrade process of the second program. Since the upgrade process does not require connecting to a dedicated emulator, but is completed by the first program in the target system, the dependence on additional hardware devices is reduced, reducing hardware costs. In addition, the upgrade file is directly received and processed by the internal program of the target system, which can significantly improve the efficiency of program updates. The upgrade file can also achieve targeted function updates and enhance the flexibility of updates. For a small number of updates, the update work can be completed more quickly and efficiently by specifying the address update method in the upgrade file. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings, which constitute part of this application, are intended to provide a further understanding of this application. The exemplary embodiments and descriptions of this application are intended to explain this application and do not constitute an improper limitation on this application. In the accompanying drawings:

[0023] Figure 1 A hardware structure block diagram of a computer terminal for implementing a program upgrade method is shown;

[0024] Figure 2 This is the process of the program upgrade method provided in the embodiment of the present application Figure 1 ;

[0025] Figure 3This is the process of the program upgrade method provided in the embodiment of the present application Figure 2 ;

[0026] Figure 4 This is the process of the program upgrade method provided in the embodiment of the present application Figure 3 ;

[0027] Figure 5 This is a waveform diagram provided according to the embodiment of the present application. Figure 1 ;

[0028] Figure 6 This is a waveform diagram provided according to the embodiment of the present application. Figure 2 ;

[0029] Figure 7 This is the process of the program upgrade method provided in the embodiment of the present application Figure 4 ;

[0030] Figure 8 This is the process of the program upgrade method provided in the embodiment of the present application Figure 5 ;

[0031] Figure 9 This is a schematic diagram of code burning according to the embodiment of this application. Figure 1 ;

[0032] Figure 10 This is a schematic diagram of code burning according to the embodiment of this application. Figure 2 ;

[0033] Figure 11 is a schematic diagram of an upgrade system for a program provided in an embodiment of the present application;

[0034] Figure 12 is a schematic diagram of an upgrade device for a program provided in an embodiment of the present application;

[0035] Figure 13 This is a structural block diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0036] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0037] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0038] First, some nouns or terms that appear in the description of the embodiments of the present application are subject to the following interpretations:

[0039] A DSP (Digital Signal Processor) is a microprocessor with a specialized architecture designed specifically for digital signal processing tasks such as filtering, encoding, decoding, compression, and decompression. It is particularly well-suited for processing large amounts of data in real time. DSPs offer high-speed data processing capabilities, powerful computational capabilities (especially for multiplication and accumulation operations), efficient memory management, and flexible I / O interfaces. These features make them crucial in a variety of fields, including communications, audio, video, image processing, biomedical engineering, radar, seismic data processing, and instrument measurement.

[0040] Boot ROM, or Boot Read-Only Memory, is a special type of memory in embedded systems. Its main function is to execute the initial boot program when the device is powered on or reset.

[0041] Boot Loader is a key component of computer hardware system, especially in embedded system. It is located between the operating system and hardware and is responsible for loading and initializing the operating system or other executable software at the initial stage of system startup.

[0042] It should be noted that the collected information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display and analysis, etc.) involved in this application are information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data comply with relevant laws, regulations, and standards, adopt necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation portals for users to choose to authorize or refuse. For example, an interface is set up between this system and relevant users or institutions, providing users with corresponding operation portals for users to choose to agree or refuse the automated decision results; if the user chooses to refuse, the expert decision-making process will be entered.

[0043] Example 1

[0044] According to an embodiment of the present application, an embodiment of a method for upgrading a program is also provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0045] The method embodiment provided in the first embodiment of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 The following is a hardware block diagram of a computer terminal (or mobile device) for implementing a program upgrade method. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (illustrated as 102a, 102b, ..., 102n in the figure) (the processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0046] It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuitry." This data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be fully or partially integrated into any of the other components of the computer terminal 10 (or mobile device). As discussed in the embodiments of this application, this data processing circuitry functions as a processor control (e.g., selecting a variable resistor terminal path connected to an interface).

[0047] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the program upgrade method in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, implementing the above-mentioned program upgrade method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely located relative to the processor 102, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0048] Transmission device 106 is configured to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by the communications provider of computer terminal 10. In one embodiment, transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, transmission device 106 may be a radio frequency (RF) module configured to communicate with the Internet wirelessly.

[0049] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 (or mobile device).

[0050] Under the above operating environment, this application provides Figure 2 How to upgrade the program shown. Figure 2 This is a flowchart of the method for upgrading the program according to Example 1 of the present application.

[0051] Step S201: receiving an upgrade file through a first program in a target system, wherein the upgrade file is used to upgrade a second program in the target system.

[0052] Optionally, when a program (i.e., the second program) in the DSP embedded system (i.e., the target system) needs to be upgraded, an upgrade file for upgrading the second program in the target system is received by the first program in the DSP embedded system. The first program can start running after the DSP embedded system is started.

[0053] In an optional embodiment, the first program can be implemented using a main function and a timer, wherein the main function determines the upgrade instruction, and the timer performs corresponding instruction processing and upgrade file parsing and burning functions.

[0054] In an optional embodiment, the upgrade file can be sent to the first program via a host computer, and the host computer can exchange data with the first program via a serial port.

[0055] It should be noted that the first and second programs can be stored in different sectors of the Flash memory. A CMD file is used to constrain program storage space and segment allocation. The first program entry address is 0x80000, and the second program entry address is 0x088000. CMD files, or Link Command Files, end with the suffix .cmd and are often referred to as CMD files. Their main functions are to indicate storage space and allocate segments to storage space. CMD file constraints are the default for DSP chips and are generally unchangeable. Memory space allocation is performed on demand.

[0056] After the target system is powered on and reset, it retrieves the reset vector from the internal Boot Rom. The reset vector points to the Boot Rom and executes the internal Boot Loader program. After execution is complete, the first program is launched from the internal Flash. The program pointer jumps to 0x080000 in the Flash, changing the address to the fixed program entry address in the Flash. The CMD file constrains the program's storage space and allocates segments to the storage space. The first program uses 0x080000 as the entry address and is stored in the PROGRAM_SECTOR sector. If the second program does not need to be upgraded, the first program jumps to the second program. The second program's entry address is configured to 0x088000 and is stored in the sector after the first program.

[0057] By storing the first program and the second program in different sectors of the FLASH, interference between the two programs can be avoided in the design. For application developers, they only need to focus on the functional implementation of the business code. For those who are porting the first program, hardware compatibility is more important. The first program is not affected by the application, and the portability of later projects is stronger. In addition, in terms of security, the integrity of the first program can always be guaranteed. During the upgrade process, only the memory space of the second program is operated. Based on the handshake mechanism and error retransmission, even if the second program fails to upgrade, the firmware can be downloaded and upgraded again without causing the first program to crash and fail to run, and the reliability of the first program can always be guaranteed. Based on the above two points, the portability and security of the upgrade mechanism can be guaranteed.

[0058] Step S202: parsing and reading the upgrade file through the first program to obtain code data corresponding to the upgrade file.

[0059] Optionally, after receiving the upgrade file, the upgrade file is parsed and read by the first program. For example, the first program reads each line of code data in the upgrade file, extracts the starting address therefrom, parses the data length field in each line and the code data that needs to be updated in the target system, etc.

[0060] In an optional embodiment, the format of the upgrade file can be an upgrade file in .hex format. The .hex format is usually used to store program code or data so that these codes and data can be written into the DSP embedded system using a programmer or software tool during the production process or during system maintenance.

[0061] Step S203 : upgrading the second program in the target system according to the code data corresponding to the upgrade file.

[0062] Optionally, the first program upgrades the second program in the target system based on the code data corresponding to the read upgrade file. For example, the first program finds the code in the second program in the target system that needs to be upgraded and then burns the code based on the read code to upgrade the second program in the target system.

[0063] In summary, in this solution, the first program set in the target system is used to receive the upgrade file, and the dependence on the dedicated emulator is eliminated through the first program. The upgrade file is parsed and read by the first program to obtain the corresponding code data. After extracting the code data of the upgrade file, the first program burns the read code data to the corresponding position to implement the upgrade process of the second program. Since the upgrade process does not require the connection of a dedicated emulator, but is completed by the first program in the target system, the dependence on additional hardware devices is reduced, the hardware cost is reduced, and the upgrade file is directly received and processed by the internal program of the target system, which can significantly improve the efficiency of program updates, and the upgrade file can achieve targeted function updates to enhance the flexibility of updates. For a small number of updates, the update work can be completed more quickly and efficiently by specifying the address update method in the upgrade file.

[0064] Optionally, in the program upgrade method provided in the embodiment of the present application, upgrading the second program in the target system based on the code data corresponding to the upgrade file includes: reading the current line of code data in the upgrade file, if the data type corresponding to the current line of code data is a preset first value, obtaining the starting address from the current line of code data, determining the sector corresponding to the starting address as the current sector, and erasing the current sector, wherein the starting address is the flag address of the current sector storing the second program; reading the next line of code data in the upgrade file, if the data type corresponding to the next line of code data is a preset second value, obtaining the offset address from the next line of code data; determining the target address based on the offset address and the starting address, and burning the next line of code data to the target address to upgrade the second program.

[0065] In an optional embodiment, upgrading the second program in the target system based on code data corresponding to the upgrade file includes the following steps: reading a current line of code data from the upgrade file and checking the data type of the line. If the data type of the current line of code data is equal to a preset first value (e.g., 4), the current line of code data is the first line, and the line of code data includes a new starting address, which identifies the beginning of a new sector. This sector needs to be erased in order to update the second program.

[0066] If the data type of the current line of code data is determined to be equal to a preset first value, a starting address is extracted from the current line of code data. This address indicates the start position of the current sector. After obtaining the starting address, the current sector can be directly erased. After the erasure is complete, the next line of code data in the upgrade file is read. After reading the next line of code data, it is determined whether the data type corresponding to the next line of code data is a preset second value (e.g., 0).

[0067] If the data type corresponding to the next line of code data is a preset second value, it indicates that the upgrade code is included in the line of code data. The offset address is first parsed from this line of data. The offset address refers to the offset relative to the previously determined starting address. The offset address is added to the starting address to calculate the actual target address. This address indicates where in the Flash to burn the new data. Finally, the new code data in the next line of code data is burned to the target address to upgrade the second program. It should be noted that the first program can realize the burning of code data by calling the Flash API.

[0068] It should be noted that the above process will be repeated until all rows of data in the upgrade file are processed or the end identifier of the file is encountered.

[0069] In an alternative embodiment, the Figure 3 The flowchart shown implements the upgrade process of the second program, which specifically includes: the target system is powered on, the Boot loader program is run first, the first program is started in the Flash, and then communication is established with the host computer to obtain the upgrade file. The host computer and the first program can use SCI serial port communication. When an online upgrade is required, the first program erases the corresponding sector according to the upgrade file, and then burns the data into the corresponding sector. When no upgrade is required, the first program directly jumps to the second program. Figure 3 As shown, the first program uses 0x080000 as the entry address, and the first program is stored in the PROGRAM_SECTOR sector (from 0x080002-0x087FFF). The second program entry address is configured as 0x088000, and the program is stored in the FLASHE sector (starting from 0x088010).

[0070] In summary, by erasing and burning only necessary sectors and data, the efficiency of the second program is improved.

[0071] Optionally, in the program upgrade method provided in the embodiment of the present application, burning the next line of code data to the target address includes: determining whether the target address is within the current sector to obtain a first judgment result; if the first judgment result indicates that the target address is within the current sector, burning the next line of code data to the target address.

[0072] If the first judgment result indicates that the target address is not within the current sector, the erase flag is set to a preset third value; when the erase flag is set to the preset third value, the current sector is updated to the sector corresponding to the target address, and the current sector is erased; after the current sector row is erased, the next row of code data is burned to the target address.

[0073] In an optional embodiment, sectors must be erased before programming. Sector erasure can only be performed on a continuous address (one sector). Before programming, it is necessary to ensure that the sector has been erased and that repeated erasure is not possible. Otherwise, each time a new address is programmed, the previous address data will be erased. Therefore, before programming the next line of code data to the target address, to avoid repeated erasure of the current sector, the following step is performed: determining whether the target address is within the current sector. If the target address is indeed within the current sector, the programming operation can proceed directly, writing the next line of code data to the target address.

[0074] When the target address is not within the current sector, it means that the new data needs to be written to a different sector. Therefore, the erase flag needs to be set to a preset third value (eg, 1) to indicate that the sector corresponding to the target address needs to be erased.

[0075] After setting the erase flag, when the erase flag is set to a preset third value, the current sector is updated to the sector corresponding to the target address, that is, in the subsequent code data burning process, it is necessary to compare whether the address corresponding to the subsequent code data is within the sector corresponding to the target address. After the current sector is updated to the sector corresponding to the target address and determined as the current sector, the current sector is erased according to the erase flag. After the erasure is completed, the next line of code data is burned to the target address, thereby completing the data update of the new sector. It should be noted that after the current sector is erased, the erase flag needs to be set to a preset value (for example, 0) to avoid the current sector being erased again in the future.

[0076] By dynamically updating the current sector and performing the erase operation at the right time, it is possible to handle program updates across multiple sectors without affecting the data in other sectors, thereby improving the accuracy of program upgrades.

[0077] Optionally, in the program upgrade method provided in the embodiment of the present application, burning the next line of code data to the target address to upgrade the second program includes: after burning the next line of code data to the target address, repeating the step of reading the next line of code data in the upgrade file until the data type corresponding to the next line of code data is a preset fourth value, then determining that the upgrade processing of the second program by the upgrade file has been completed.

[0078] In an optional embodiment, as described above, after programming the next line of code data to the target address, the first program continues to read the next line of code data from the upgrade file, i.e., repeatedly performs the step of reading the next line of code data from the upgrade file until the data type corresponding to the next line of code data is a predetermined fourth value (e.g., 1). When it is determined that the data type corresponding to the next line of code data is the predetermined fourth value, it indicates that all data records in the upgrade file have been read, and the upgrade process of the second program by the upgrade file has been completed.

[0079] By parsing and burning the code data in the upgrade file line by line, it is possible to ensure that the upgrade process of the second program is complete and correct, thereby improving the accuracy of the program upgrade.

[0080] Optionally, in the program upgrade method provided in the embodiment of the present application, upgrading the second program in the target system based on the code data corresponding to the upgrade file includes: determining whether the frame header mark corresponding to the upgrade file is a preset character; if the frame header mark is a preset character, upgrading the second program in the target system based on the code data corresponding to the upgrade file.

[0081] In one readable embodiment, to avoid receiving a faulty upgrade file, when performing an upgrade process on a second program in a target system using code data corresponding to the upgrade file, the first program needs to determine whether the header flag corresponding to the upgrade file is a preset character (e.g., 0x3A). If the header flag is a preset character, the second program in the target system is upgraded based on the code data corresponding to the upgrade file.

[0082] It should be noted that if the frame header mark corresponding to the upgrade file is not a preset character, it indicates that there may be a problem with the upgrade file, and therefore, the upgrade file needs to be obtained again.

[0083] By checking the frame header flag, you can ensure that the transmission and reception of the upgrade file are correct, and also prevent erroneous data streams from being mistaken for valid upgrade files, thereby avoiding unnecessary errors and possible system damage.

[0084] In an alternative embodiment, the Figure 4The flowchart shown implements burning a code file. First, the first program checks whether the frame header flag corresponding to the upgrade file is 0x3A. If it is, it reads the current line of code data and determines whether the corresponding data type is 1. If not, it reads the length, address, and checksum of the current line of code data. The checksum is used to determine whether there are errors in the current line of code data. If not, the data to be burned is read from the current line of code data and a check is made to determine whether the end of the line has been reached. If the end of the line has been reached, the data type corresponding to the current line of code data is determined to be 4. If it is 4, this indicates that the current line of code data is the first line of code data. The starting address is read from the current line of code data and recorded, and the next line of code data is read. If the end of the line has not been reached, Received_Data_Index++ (used to increment the received data index or count when processing received data in the program) is called until the end of the line is reached. If the data type corresponding to the current line of code data is 0, the offset address in the current line of code data is read, and the absolute address corresponding to the current line of code data (i.e., the target address mentioned above) is calculated based on the offset address and the recorded starting address. Based on the absolute address, it is determined whether to set the sector erase flag to 1. If the sector erase flag is 1, the sector is erased and the data to be burned in the current line of code data is burned. After the burning is completed, the file offset is upgraded to read the next line of code data, and a processing completion flag is set for the current line of code data. The above process is repeated until the data type corresponding to the read code data is 1. If the data type corresponding to the read code data is 1, the cache area used to store the upgrade file is cleared, and the flag of the cache area is set to 1, indicating that the current upgrade file has been processed.

[0085] If the frame header flag corresponding to the upgrade file is not 0x3A, it indicates that there may be a problem with the upgrade file. Therefore, the buffer used to store the upgrade file is cleared and an error (HEXFILE_ERR) is reported. If the checksum determines that there is an error in the current line of code data, the error line number is sent, the buffer used to store the upgrade file is cleared, and an error (HEX CHECK_ERR) is reported.

[0086] Through data type recognition, automated sector erasure and data burning, as well as sophisticated error handling and upgrade progress control, the efficiency and security of program upgrades are greatly improved. Especially in the scenario of online upgrades, it can effectively reduce the risks during the upgrade process and increase the success rate of upgrades, thereby supporting the maintainability and flexibility of embedded systems.

[0087] Optionally, in the program upgrade method provided in the embodiment of the present application, after the second program in the target system is upgraded based on the code data corresponding to the upgrade file, the method further includes: determining whether there is a next upgrade file to obtain a second judgment result; if the second judgment result indicates that there is a next upgrade file, the second program in the target system is upgraded based on the next upgrade file until there is no next upgrade file; if the second judgment result indicates that there is no next upgrade file, a target signal is triggered, wherein the target signal is used to indicate that the upgrade process of the second program has been completed.

[0088] In an optional embodiment, after upgrading the second program in the target system using the code data corresponding to the upgrade file, the first program determines whether there is a next upgrade file to be processed. If so, the first program begins processing it, including steps such as reading the file, parsing the data, erasing sectors, burning data, and verifying integrity. This process is repeated until all upgrade files have been correctly processed.

[0089] After determining that there is no next upgrade file, that is, all files to be upgraded have been burned, the first program can send a target signal to indicate that the program upgrade process has been completed. The target signal can be implemented in many ways, such as sending a confirmation message through the serial port.

[0090] In an optional embodiment, after the upgrade process of the second program is completed, the waveform can be captured by an oscilloscope to compare whether the upgrade of the second program is successful. If different flip frequencies are seen, it means that the upgrade is successful. For example, the waveform of the second program before the upgrade is as follows: Figure 5 As shown, the duration of the high level is about 1s. The waveform of the second program after upgrading is as follows Figure 6 As shown, the duration of the high level is about 4 seconds. Through the above steps, it can be accurately evaluated whether the second program is upgraded.

[0091] Optionally, in the program upgrade method provided in the embodiment of the present application, after receiving the upgrade file through the first program in the target system, the method also includes: storing the upgrade file in a receiving cache area; determining whether there is an error in the upgrade file in the receiving cache area; if there is an error in the upgrade file in the receiving cache area, resetting the receiving cache area and re-receiving the upgrade file.

[0092] The program upgrade method provided in the embodiment of the present application also includes: reading the upgrade file from the receiving buffer area through the first program; when reading the upgrade file, determining whether there is an overflow in the receiving buffer area; if there is an overflow in the receiving buffer area, resetting the receiving buffer area and re-receiving the upgrade file.

[0093] In an optional embodiment, the first program can implement the reception and storage of the upgrade file by the following steps: The reception of the upgrade file can be implemented by using a 3s timer interrupt. The 3s timer is an actual test value of the project to ensure the complete reception of the upgrade file. For example, Figure 7 As shown, the system first determines whether a new message has been received (i.e., whether the upgrade file has been received). If a new message is received, the received data timestamp is reset, and the received upgrade file is stored in the receive buffer. Next, the system determines whether the received upgrade file contains errors. If so, the receive buffer is reset, and the upgrade file is accurately received again.

[0094] If the received upgrade file contains no errors, the system determines whether to read the upgrade file from the receive buffer. If so, the system determines whether the receive buffer overflows. If not, the upgrade file is processed normally. If so, the receive data flag is reset (accurately re-receive the upgrade file) and the receive buffer is cleared.

[0095] In an optional embodiment, after the first program receives data and places it into a receive buffer, a timer interrupt scans the buffer data every 3 seconds. If there is new data, the data content is determined and processed. The first program can also receive Modbus instructions in addition to upgrade files. Modbus instructions are specific commands or functions used in the Modbus communication protocol to send and receive data. They define how to exchange information between Modbus master devices (Master) and slave devices (Slave). The Modbus protocol is a serial communication protocol widely used in industrial automation. It allows different devices to exchange data through standard interfaces and commands. Modbus instructions can include read instructions and write instructions.

[0096] Therefore, when the first program starts to process the received data, it is necessary to first determine whether it is a Modbus instruction or a HEX upgrade file, such as Figure 8 As shown, the first character is checked to see if it is a Slave ID. If so, it indicates a Modbus command. For Modbus commands, the Modbus receive flag is set, and then the function code is determined to be correct. If the function code is correct, the complete message is received and verified (i.e., CRC check). If an error is found, an error is reported and the cache is cleared. If the verification is correct, the data frame is correct, and the corresponding function processing is performed.

[0097] For HEX upgrade files, set the HEX receive flag and process the HEX upgrade file every 400us, that is, determine the data type of the data line, calculate the data length, address, and checksum. Determine the erase sector flag based on the address and then erase or burn the data.

[0098] Through the above steps, the program upgrade method provided in the embodiment of the present application can effectively handle and avoid common errors in data transmission, such as data corruption, data overflow, etc., thereby ensuring the integrity of the upgrade file and the reliability of data transmission.

[0099] Optionally, in the program upgrade method provided in the embodiment of the present application, before receiving the upgrade file through the first program in the target system, the method also includes: generating an initial upgrade file based on the functional information to be upgraded through the target host computer; judging whether the initial upgrade file needs to be split based on the target threshold through the target host computer; if the initial upgrade file needs to be split, splitting the initial upgrade file based on the target threshold through the target host computer to obtain multiple upgrade files; and transmitting each upgrade file to the first program through the target host computer.

[0100] In an optional embodiment, the program upgrade method provided herein can be used to transfer the upgrade file to the first program in the following manner: On the target host computer, software is compiled based on the functional information to be upgraded (e.g., new features, bug fixes, optimized performance parameters, etc.) to generate an initial upgrade file. This file can include all necessary update data and is stored in .hex format.

[0101] Since the first program has limited ability to process the upgrade file at one time, the target host computer needs to determine whether the initial upgrade file needs to be split based on the target threshold. It should be noted that the target threshold can be the ability threshold of the first program to process the upgrade file at one time.

[0102] If the initial upgrade file needs to be split, the target host computer splits the initial upgrade file based on the target threshold, and finally transmits each split upgrade file to the first program via the target host computer. It should be noted that since the first line of the complete initial upgrade file contains the starting address of the sector and the last line contains the ending mark, when splitting the upgrade file, it is necessary to perform supplementary processing on the upgrade file that lacks the starting address or ending mark.

[0103] It should be noted that the target host computer needs to read the response of the register corresponding to the first program according to a preset time period to determine whether the upgrade file is successfully sent.

[0104] By splitting a large file into multiple smaller files for transmission, you can avoid transmission delays or failures caused by excessive single data transfers, especially when network bandwidth is limited or unstable, which can improve data transmission efficiency and success rate. Splitting the hex file on the target host computer makes it easier to operate, and for the first program, it only needs to receive the split smaller files sent by the target host computer, and the file processing logic remains unchanged (burning data according to the address), which improves the first program's processing efficiency for upgrading files.

[0105] Optionally, in the program upgrade method provided in an embodiment of the present application, before receiving the upgrade file through the first program in the target system, the method also includes: starting the boot loader after the target system receives a power-on signal; starting the first program through the boot loader, and establishing a communication mechanism between the first program and the target host computer so that the first program can receive the upgrade file.

[0106] In an optional embodiment, after the target system receives a power-on signal, it launches a boot loader (i.e., a program). Once the boot loader completes initialization, it launches the first program and performs initialization operations for the first program. For example, it initializes and sets the functions of relevant GPIO (general purpose input and output) pins, configures interrupt functions and enables serial port interrupts, initializes and configures the frequency of timers and enables interrupts, etc. Furthermore, a communication mechanism is established between the first program and the target host computer, enabling the first program to receive the upgrade file. In an optional embodiment, the first program and the target host computer can communicate via an RS485 serial port.

[0107] In an optional embodiment, the initialization process includes initializing the GPIO (General Purpose Input / Output) port, initializing the SCI serial port for RS485 communication, setting the baud rate to 115200, 8 data bits, 1 stop bit, and even parity. It also initializes Timer 0, configuring the Timer 0 frequency to 200 μs, and enabling the timer interrupt.

[0108] In an optional embodiment, the program upgrade method provided in the embodiment of the present application mainly involves two main entities: an underlying program (i.e., the first program described above) and a host computer. The underlying program is implemented using a main function + timer. The main function determines the upgrade instruction, and the timer performs corresponding instruction processing and upgrade file parsing and burning functions. It includes system hardware interface initialization, serial port communication data processing, HEX data extraction (i.e., upgrade file extraction), on-chip Flash erasing and burning, and application program (i.e., the second program described above) jump. The host computer is divided into a serial port configuration module and an upgrade test module, which are responsible for serial port configuration, open-loop control, and the selection, splitting, distribution, and progress display of firmware upgrade files.

[0109] When the target system is powered on, the Boot loader program runs first. The underlying program establishes serial communication with the host computer via an RS485-USB connection. The underlying program receives host computer instructions and HEX upgrade files, and performs sector erase and programming or jumps to the application program as required. The host computer selects the local HEX upgrade file and automatically splits and distributes it in batches, displaying the upgrade process.

[0110] The low-level program performs the following steps: Serial communication data processing: Initializes the SCI serial port, adheres to the Modbus protocol, and uses timer interrupts to receive data (storing it in the receive buffer), process it (distinguishing between Modbus commands and HEX upgrade files and processing them separately), and send it (processed in a timer interrupt with a 200µs delay before sending). HEX data extraction: Uses a 400µs timer interrupt to process the HEX upgrade file line by line, determining the data type, calculating relevant parameters, and determining sector operations based on the address. CMD file constraints: The low-level program and application are stored in different FLASH sectors. The CMD file constrains program storage space and segment allocation. The low-level program entry address is 0x80000, and the application entry address is 0x088000. On-chip Flash erase and write: Based on the input address, data, and number to be written, the FLASH API is initialized. After determining the sector erase flag, the erase and write operation is performed and the Flash pump is released. Application jump: Uses assembly code to jump to the application start address.

[0111] The host computer performs the following steps: CCS generates a HEX file: Configure the simulation software to generate a HEX file. Host computer file processing: The host computer splits the file, while the underlying program only processes the standard HEX file. After sending the file, the host computer determines the upgrade status and displays the progress based on the underlying program's response and the configured timeout. Upgrade testing: Verifies the firmware upgrade functionality through steps such as underlying program programming, upgrade file reception testing, flash erase and programming testing, and system status indicator pin waveform testing.

[0112] In an optional embodiment, the upgrade test of the application can be implemented through the following steps. First, the underlying program can be burned into the Flash of the target program. Click the upgrade file on the host computer, select the HEX upgrade file, click Start Download, and start sending data. The received buffer data (i.e. the HEX upgrade file received by the underlying program) is compared with the source data to determine that the received test data is correct. When the application processes the HEX file, if the sector erase flag is 1, erase the corresponding sector, such as Figure 9 As shown, erase the sector Flash. Figure 9 FFFF in the table indicates that the sector has been erased. After the sector is erased, write data to the corresponding address. Figure 10As shown, the selected area is the data being programmed. Open the host computer and send the upgrade file. The progress bar will display the upgrade process, and when the download is complete, the message "Upgrade Successful" will appear. By capturing the waveform using an oscilloscope, you can see different flip frequencies, indicating a successful upgrade.

[0113] The program upgrade method provided in the embodiment of the present application receives an upgrade file through a first program in a target system, wherein the upgrade file is used to upgrade a second program in the target system; the upgrade file is parsed and read by the first program to obtain code data corresponding to the upgrade file; and the second program in the target system is upgraded based on the code data corresponding to the upgrade file, thereby solving the technical problem in the related art of requiring the application program in the processor to be updated by connecting to an emulator, resulting in relatively low update efficiency of the application program.

[0114] In this solution, a first program installed in the target system receives the upgrade file, eliminating the need for a dedicated emulator. The first program parses and reads the upgrade file to obtain the corresponding code data. After extracting the code data from the upgrade file, the first program burns the read code data to the corresponding location to upgrade the second program. Because the upgrade process does not require a dedicated emulator and is instead completed through the first program in the target system, the reliance on additional hardware devices and hardware costs are reduced. Furthermore, by directly receiving and processing the upgrade file through the target system's internal program, the efficiency of program updates can be significantly improved, enhancing the flexibility of updates.

[0115] It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and that, although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0116] Example 2

[0117] According to an embodiment of the present application, a program upgrade system is also provided. It should be noted that the program upgrade system of the embodiment of the present application can be used to execute the program upgrade method provided in the embodiment of the present application. The program upgrade system provided in the embodiment of the present application is introduced below.

[0118] According to an embodiment of the present application, a program upgrade system for implementing the above program upgrade method is also provided. Figure 11 As shown, the upgrade system includes: a target host computer 1101 and a first program 1102.

[0119] A target host computer 1101, wherein the target host computer is used to generate an upgrade file and transmit the upgrade file to the first program;

[0120] The first program 1102 upgrades the second program in the target system based on the upgrade file.

[0121] like Figure 11 As shown, the upgrade system includes: a target host computer 1101 and a first program 1102. First program 1102 is implemented using a main function + timer. The main function determines the upgrade instruction, and the timer processes the corresponding instruction and parses and burns the upgrade file. This includes system hardware interface initialization, serial communication data processing, HEX data extraction (i.e., upgrade file extraction), on-chip Flash erasing and burning, and application program jump (i.e., the second program mentioned above). Target host computer 1101 is divided into a serial port configuration module and an upgrade test module, responsible for serial port configuration, open-loop control, and the selection, splitting, distribution, and progress display of firmware upgrade files.

[0122] When the target system is powered on, the Boot loader program is first run. The first program 1102 establishes serial communication with the target host computer 1101 through the RS485-USB connection. The first program 1102 receives the target host computer 1101 instructions and HEX upgrade files, and performs sector erase and burn or jumps to the application program according to requirements. The target host computer 1101 selects the local HEX upgrade file and automatically splits and sends it in batches, displaying the upgrade process.

[0123] First program 1102 is used to perform the following steps: Serial communication data processing: Initializes the SCI serial port, adheres to the Modbus protocol, and uses timer interrupts to receive data (storing it in the receive buffer), process it (distinguishing between Modbus commands and HEX upgrade files and processing them separately), and send it (processed in a timer interrupt with a 200µs delay before sending). HEX data extraction: Uses a 400µs timer interrupt to process the HEX upgrade file line by line, determining the data type, calculating relevant parameters, and determining sector operations based on the address. CMD file constraints: First program 1102 and the application are stored in different FLASH sectors. CMD files constrain program storage space and segment allocation. The entry address of first program 1102 is 0x80000, and the entry address of the application is 0x088000. On-chip FLASH erase and write: Based on the input address, data, and number to be written, the FLASH API is initialized. After determining the sector erase flag, erase and write operations are performed and the flash pump is released. Application jump: Uses assembly code to jump to the application start address.

[0124] Target host computer 1101 is configured to perform the following steps: CCS generates a HEX file: Configure the simulation software to generate a HEX file. Target host computer 1101 processes the file: Target host computer 1101 splits the file, while first program 1102 only needs to process the standard HEX file. After sending the file, target host computer 1101 determines the upgrade status and displays the progress based on the response from first program 1102 and the set timeout. Upgrade testing: Verifies the firmware upgrade functionality through steps such as first program 1102 programming, upgrade file reception testing, flash erase and programming testing, and system status indicator pin waveform testing.

[0125] In summary, in this solution, the first program set in the target system is used to receive the upgrade file, and the first program eliminates the dependence on the dedicated emulator. The first program parses and reads the upgrade file to obtain the corresponding code data. After extracting the code data of the upgrade file, the first program burns the read code data to the corresponding location to implement the upgrade process of the second program. Since the upgrade process does not require connecting to a dedicated emulator, but is completed through the first program in the target system, the dependence on additional hardware devices is reduced, the hardware cost is reduced, and the upgrade file is directly received and processed by the internal program of the target system, which can significantly improve the efficiency of program updates and enhance the flexibility of updates.

[0126] Example 3

[0127] The present application also provides a program upgrade device. It should be noted that the program upgrade device of the present application can be used to execute the program upgrade method provided in the present application. The program upgrade device provided in the present application is introduced below.

[0128] According to an embodiment of the present application, a program upgrade device for implementing the above program upgrade method is also provided, such as Figure 12 As shown, the device includes: a receiving unit 1201 , a processing unit 1202 and a first upgrading unit 1203 .

[0129] A receiving unit 1201 is configured to receive an upgrade file through a first program in a target system, wherein the upgrade file is used to upgrade a second program in the target system;

[0130] The processing unit 1202 is configured to parse and read the upgrade file through the first program to obtain code data corresponding to the upgrade file;

[0131] The first upgrading unit 1203 is configured to upgrade the second program in the target system according to the code data corresponding to the upgrading file.

[0132] The program upgrade device provided in the embodiment of the present application receives an upgrade file through the first program in the target system through the receiving unit 1201, wherein the upgrade file is used to upgrade the second program in the target system; the processing unit 1202 parses and reads the upgrade file through the first program to obtain code data corresponding to the upgrade file; the first upgrade unit 1203 upgrades the second program in the target system according to the code data corresponding to the upgrade file, thereby solving the technical problem in the related art that the application program in the processor needs to be updated by connecting to an emulator, resulting in relatively low update efficiency of the application program.

[0133] In this solution, the first program set in the target system is used to receive the upgrade file, and the first program eliminates the dependence on the dedicated emulator. The first program parses and reads the upgrade file to obtain the corresponding code data. After extracting the code data of the upgrade file, the first program burns the read code data to the corresponding location to implement the upgrade process of the second program. Since the upgrade process does not require connecting to a dedicated emulator, but is completed by the first program in the target system, the dependence on additional hardware devices is reduced, reducing hardware costs. In addition, the upgrade file is directly received and processed by the internal program of the target system, which can significantly improve the efficiency of program updates. The upgrade file can also achieve targeted function updates and enhance the flexibility of updates. For a small number of updates, the update work can be completed more quickly and efficiently by specifying the address update method in the upgrade file.

[0134] Optionally, in the program upgrade device provided in the embodiment of the present application, the first upgrade unit includes: a first reading module, used to read the current line of code data in the upgrade file, if the data type corresponding to the current line of code data is a preset first value, then obtain the starting address from the current line of code data, determine the sector corresponding to the starting address as the current sector, and erase the current sector, wherein the starting address is the flag address of the current sector storing the second program; a second reading module, used to read the next line of code data in the upgrade file, if the data type corresponding to the next line of code data is a preset second value, then obtain the offset address from the next line of code data; a determination module, used to determine the target address based on the offset address and the starting address, and burn the next line of code data to the target address to upgrade the second program.

[0135] Optionally, in the upgrade device of the program provided in the embodiment of the present application, the determination module includes: a judgment submodule, used to judge whether the target address is within the current sector and obtain a first judgment result; and a burning submodule, used to burn the next line of code data to the target address if the first judgment result indicates that the target address is within the current sector.

[0136] Optionally, in the program upgrade device provided in the embodiment of the present application, the device also includes: a setting unit, which is used to determine whether the target address is within the current sector, and after obtaining a first judgment result, if the first judgment result indicates that the target address is not within the current sector, set the erase flag to a preset third value; an update unit, which is used to update the current sector to the sector corresponding to the target address and erase the current sector when the erase flag is set to the preset third value; and a burning unit, which is used to burn the next line of code data to the target address after erasing the current sector.

[0137] Optionally, in the program upgrade device provided in the embodiment of the present application, the determination module includes: an execution sub-module, which is used to repeatedly execute the step of reading the next line of code data in the upgrade file after burning the next line of code data to the target address, until the data type corresponding to the next line of code data is a preset fourth value, and then it is determined that the upgrade processing of the second program by the upgrade file has been completed.

[0138] Optionally, in the program upgrade device provided in the embodiment of the present application, the device also includes: a first judgment unit, used to judge whether there is a next upgrade file after the second program in the target system is upgraded according to the code data corresponding to the upgrade file, and obtain a second judgment result; a second upgrade unit, used to upgrade the second program in the target system based on the next upgrade file if the second judgment result indicates that there is a next upgrade file, until there is no next upgrade file; a trigger unit, used to trigger a target signal if the second judgment result indicates that there is no next upgrade file, wherein the target signal is used to indicate that the upgrade process of the second program has been completed.

[0139] Optionally, in the program upgrade device provided in the embodiment of the present application, the device also includes: a storage unit, used to store the upgrade file in a receiving cache area after receiving the upgrade file through the first program in the target system; a second judgment unit, used to judge whether there is an error in the upgrade file in the receiving cache area; and a first reset unit, used to reset the receiving cache area and re-receive the upgrade file if there is an error in the upgrade file in the receiving cache area.

[0140] Optionally, in the program upgrade device provided in the embodiment of the present application, the device also includes: a reading unit, which is used to read the upgrade file from the receiving buffer area through the first program before upgrading the second program in the target system according to the code data corresponding to the upgrade file; a third judgment unit, which is used to judge whether there is an overflow in the receiving buffer area when reading the upgrade file; and a second reset unit, which is used to reset the receiving buffer area and re-receive the upgrade file if there is an overflow in the receiving buffer area.

[0141] Optionally, in the program upgrade device provided in the embodiment of the present application, the device also includes: a generation unit, which is used to generate an initial upgrade file based on the functional information to be upgraded through the target host computer before receiving the upgrade file through the first program in the target system; a fourth judgment unit, which is used to judge whether the initial upgrade file needs to be split based on the target threshold through the target host computer; a splitting unit, which is used to split the initial upgrade file based on the target threshold through the target host computer to obtain multiple upgrade files if the initial upgrade file needs to be split; and a transmission unit, which is used to transmit each upgrade file to the first program through the target host computer.

[0142] Optionally, in the program upgrade device provided in the embodiment of the present application, the device also includes: a first startup unit, used to start the boot loader before receiving the upgrade file through the first program in the target system and after the target system receives a power-on signal; a second startup unit, used to start the first program through the boot loader and establish a communication mechanism between the first program and the target host computer so that the first program can receive the upgrade file.

[0143] Optionally, in the program upgrade device provided in the embodiment of the present application, the first upgrade unit includes: a judgment module for judging whether the frame header mark corresponding to the upgrade file is a preset character; and an upgrade module for upgrading the second program in the target system according to the code data corresponding to the upgrade file when the frame header mark is a preset character.

[0144] It should be noted that the aforementioned receiving unit 1201, processing unit 1202, and first upgrading unit 1203 correspond to steps S201 to S203 in Example 1. The examples and application scenarios implemented by these three units and the corresponding steps are the same, but are not limited to the contents disclosed in Example 1. It should be noted that the aforementioned modules or units may be hardware components or software components stored in a memory (e.g., memory 124) and processed by one or more processors (e.g., processors 122a, 122b, ..., 122n). The aforementioned modules may also be part of a device and run in the computer terminal 10 provided in Example 1.

[0145] Example 4

[0146] An embodiment of the present application may provide an electronic device, Figure 13 This is a structural block diagram of an electronic device according to an embodiment of the present application. Figure 13 As shown, the electronic device may include: one or more ( Figure 13 Only one is shown) processor 1302, memory 1304, storage controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0147] Among them, the memory can be used to store software programs and modules, such as program instructions / modules corresponding to the methods and devices in the embodiments of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, implementing the above-mentioned method. The memory may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include a memory remotely arranged relative to the processor, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network and a combination thereof.

[0148] The processor can call the information and application programs stored in the memory through the transmission device to execute the program upgrade method steps.

[0149] It can be understood by those skilled in the art that Figure 13 The structure shown is for illustration only, and the electronic device may also be a smart phone (such as , tablet computers, PDAs, mobile Internet devices (MID), PADs and other terminal devices. Figure 13 It does not limit the structure of the above electronic device. For example, the electronic device may also include Figure 13 More or fewer components (such as network interfaces, display devices, etc.) shown in, or with Figure 13 Different configurations shown.

[0150] A person skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0151] Example 5

[0152] The embodiment of the present application further provides a computer-readable storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the program upgrade method provided in the first embodiment.

[0153] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group.

[0154] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing the program steps of the program upgrade method.

[0155] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0156] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0157] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0158] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0159] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0160] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the existing technology, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for enabling a computer device (which can be a personal computer, server or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk, etc. Various media that can store program code.

[0161] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A program upgrade method, characterized in that: include: Receiving an upgrade file through a first program in a target system, wherein the upgrade file is used to upgrade a second program in the target system; Parsing and reading the upgrade file by the first program to obtain code data corresponding to the upgrade file; performing an upgrade process on the second program in the target system according to the code data corresponding to the upgrade file; wherein, reading the current line code data in the upgrade file, and if the data type corresponding to the current line code data is a preset first value, obtaining a starting address from the current line code data, determining a sector corresponding to the starting address as a current sector, and erasing the current sector. After erasing the current sector, setting an erase flag to a preset value to avoid repeated erasure of the current sector; Reading the next line of code data in the upgrade file, and if the data type corresponding to the next line of code data is a preset second value, obtaining an offset address from the next line of code data; and determining a target address based on the offset address and the starting address; If the target address is within the current sector, the next line of code data is burned to the target address; if the target address is not within the current sector, an erase flag is set to a preset third value; when the erase flag is set to the preset third value, the current sector is updated to the sector corresponding to the target address, and the current sector is erased; after the current sector is erased, the next line of code data is burned to the target address; Before receiving the upgrade file through the first program in the target system, the method further includes: generating an initial upgrade file based on the function information to be upgraded through the target host computer; determining whether the initial upgrade file needs to be split based on a target threshold through the target host computer; if the initial upgrade file needs to be split, splitting the initial upgrade file based on the target threshold through the target host computer to obtain multiple upgrade files; and transmitting each upgrade file to the first program through the target host computer; When the initial upgrade file is split, the upgrade file that lacks a start address or an end mark is supplemented. The start address is the start address of the sector of the first line in the complete initial upgrade file.

2. The method according to claim 1, characterized in that Burning the next line of code data to the target address to upgrade the second program includes: After burning the next line of code data to the target address, repeat the step of reading the next line of code data in the upgrade file until the data type corresponding to the next line of code data is a preset fourth value, then it is determined that the upgrade processing of the second program by the upgrade file has been completed.

3. The method according to claim 1, characterized in that After upgrading the second program in the target system according to the code data corresponding to the upgrade file, the method further includes: Determine whether there is a next upgrade file, and obtain a second determination result; If the second judgment result indicates that the next upgrade file exists, upgrading the second program in the target system based on the next upgrade file until the next upgrade file does not exist; If the second judgment result indicates that the next upgrade file does not exist, a target signal is triggered, wherein the target signal is used to indicate that the upgrade process of the second program has been completed.

4. The method according to claim 1, wherein After receiving the upgrade file through the first program in the target system, the method further includes: Storing the upgrade file in a receiving buffer area; Determine whether there is an error in the upgrade file in the receiving buffer area; If there is an error in the upgrade file in the receiving buffer, the receiving buffer is reset and the upgrade file is received again.

5. The method according to claim 4, characterized in that Before performing an upgrade process on the second program in the target system according to the code data corresponding to the upgrade file, the method further includes: Reading the upgrade file from the receiving buffer area through the first program; When reading the upgrade file, determining whether the receiving buffer area has overflow; If the receiving buffer overflows, the receiving buffer is reset and the upgrade file is received again.

6. The method according to claim 1, characterized in that Before receiving the upgrade file through the first program in the target system, the method further includes: After the target system receives a power-on signal, starting a boot loader; The first program is started by the boot loader, and a communication mechanism is established between the first program and the target host computer, so that the first program can receive the upgrade file.

7. The method according to claim 1, characterized in that Upgrading the second program in the target system according to the code data corresponding to the upgrade file includes: Determine whether the frame header mark corresponding to the upgrade file is a preset character; In a case where the frame header mark is the preset character, the second program in the target system is upgraded according to the code data corresponding to the upgrade file.

8. A program upgrade system, characterized in that: include: A target host computer, wherein the target host computer is used to generate an upgrade file and transfer the upgrade file to the first program; a first program, wherein the first program upgrades the second program in the target system based on the upgrade file; wherein, reading the current line code data in the upgrade file, and if the data type corresponding to the current line code data is a preset first value, obtaining a starting address from the current line code data, determining a sector corresponding to the starting address as a current sector, and erasing the current sector. After erasing the current sector, setting an erase flag to a preset value to avoid repeated erasure of the current sector; Reading the next line of code data in the upgrade file, and if the data type corresponding to the next line of code data is a preset second value, obtaining an offset address from the next line of code data; and determining a target address based on the offset address and the starting address; If the target address is within the current sector, the next line of code data is burned to the target address; if the target address is not within the current sector, an erase flag is set to a preset third value; when the erase flag is set to the preset third value, the current sector is updated to the sector corresponding to the target address, and the current sector is erased; after the current sector is erased, the next line of code data is burned to the target address; Before receiving the upgrade file through the first program in the target system, the method further includes: generating an initial upgrade file based on the function information to be upgraded through the target host computer; determining whether the initial upgrade file needs to be split based on a target threshold through the target host computer; if the initial upgrade file needs to be split, splitting the initial upgrade file based on the target threshold through the target host computer to obtain multiple upgrade files; and transmitting each upgrade file to the first program through the target host computer; When the initial upgrade file is split, the upgrade file that lacks a start address or an end mark is supplemented. The start address is the start address of the sector of the first line in the complete initial upgrade file.

9. A program upgrade device, characterized in that: include: a receiving unit, configured to receive an upgrade file through a first program in a target system, wherein the upgrade file is used to upgrade a second program in the target system; a processing unit, configured to parse and read the upgrade file through the first program to obtain code data corresponding to the upgrade file; A first upgrading unit, configured to upgrade the second program in the target system according to code data corresponding to the upgrading file; The device is further configured to read the current line code data in the upgrade file, and if the data type corresponding to the current line code data is a preset first value, obtain a starting address from the current line code data, determine the sector corresponding to the starting address as the current sector, and erase the current sector. After erasing the current sector, set an erase flag to a preset value to avoid repeated erasure of the current sector. Reading the next line of code data in the upgrade file, and if the data type corresponding to the next line of code data is a preset second value, obtaining an offset address from the next line of code data; and determining a target address based on the offset address and the starting address; If the target address is within the current sector, the next line of code data is burned to the target address; if the target address is not within the current sector, an erase flag is set to a preset third value; when the erase flag is set to the preset third value, the current sector is updated to the sector corresponding to the target address, and the current sector is erased; after the current sector is erased, the next line of code data is burned to the target address; Before receiving the upgrade file through the first program in the target system, the method further includes: generating an initial upgrade file based on the function information to be upgraded through the target host computer; determining whether the initial upgrade file needs to be split based on a target threshold through the target host computer; if the initial upgrade file needs to be split, splitting the initial upgrade file based on the target threshold through the target host computer to obtain multiple upgrade files; and transmitting each upgrade file to the first program through the target host computer; When the initial upgrade file is split, the upgrade file that lacks a start address or an end mark is supplemented. The start address is the start address of the sector of the first line in the complete initial upgrade file.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored executable program, wherein when the executable program is run, the device where the computer-readable storage medium is located is controlled to execute the program upgrade method according to any one of claims 1 to 7.

11. An electronic device, characterized in that: include: a memory storing an executable program; A processor, configured to run the program, wherein the program upgrade method according to any one of claims 1 to 7 is executed when the program is run.

Images