A method for online upgrading and curing of dynamically loaded application software on a chip

Abstract

The present invention relates to an online upgrade and solidification method for in-chip dynamically loading application software, belonging to the field of industrial control. In the present invention, a certain amount of memory is applied in the RAM as the address space of the Application Software for temporarily storing the uploaded application software data; the flash memory is divided into three parts: one part is used for storing the general-purpose boot image; one part is used for storing the operating system image; and the remaining address space is reserved. The present invention does not need to use off-chip storage devices, does not need to customize and develop a general boot program, and does not need to rely on solidification tools. It only relies on the in-chip flash memory to help users solve the problems of online upgrade, solidification and version rollback of embedded application software.

Description

Technical Field

[0001] The invention belongs to the field of industrial control, and in particular relates to an online upgrading and curing method for dynamically loading application software in a chip. Background Art

[0002] With the rapid development of electronic technology, the integration of electronic equipment is getting higher and higher, and integrated equipment is widely used in all walks of life. In the actual industrial control field, from the product development stage to the later maintenance and upgrade of the product, it is necessary to continuously improve and perfect the device terminal (lower computer) user software to adapt to new needs or optimize product performance, so it is necessary to upgrade the device terminal user software many times. Due to the limitations of hardware resources and environmental conditions, traditional embedded industrial terminal equipment needs to solidify the software code during the production stage, and once the equipment is delivered, it cannot be modified online on site. When there is a need for software upgrade or fault debugging, the product must be disassembled, the emulator interface of the product main control chip must be exposed, and a communication link must be established by connecting the solidification tool (emulator), and the program must be updated through professional software; it may even be necessary to replace the device board on site, replace the local program storage device, or return the device to the factory.

[0003] In order to meet the changing needs of users and extend the life cycle of products, the industrial control field has gradually improved and produced some more advanced upgrade and solidification methods, which the author classifies into the following categories:

[0004] (1) Secondary boot upgrade and fixation method

[0005] A secondary boot program is designed between a general boot program (such as Uboot, BootLoader, and PMON) and a system image to be responsible for the migration and startup of the system image.

[0006] This upgrade and curing method is an offline upgrade. Because the system image often needs to be cured in the flash memory, the device needs to be powered off and connected to the curing tool when the system image is upgraded, and the operation process is relatively complicated; users also need to purchase curing tools, which increases hardware costs; the operating system and application software compilation are coupled together, and once an abnormality occurs at startup, the system will not work normally and will exit.

[0007] Of course, the advantages of this method are also obvious. It can effectively get rid of the dependence on the universal boot program and there is no need to customize and modify the universal boot program. At the same time, the equipment does not need to be returned to the factory, and users can upgrade the system image by themselves at the industrial site.

[0008] (2) Dynamic loading application software upgrade and fixation method

[0009] With the improvement of computer technology, universal boot programs have supported file system management (such as FAT) and have the functions of adding, deleting, modifying and checking files on external storage devices. Users can upload system images through the network and solidify them to external storage devices through command calls for boot program loading and startup.

[0010] ① The operating system and application software can be compiled and coupled together, and directly loaded and run by the boot program. However, in this case, once the loaded system image is abnormally started, the system will not work properly and will exit.

[0011] ② The operating system and application software can be compiled separately, and the operating system image and application software can be uploaded and solidified to the external storage device respectively. The device is powered on, and the boot program loads and starts the system image. After the operating system is started, the dynamic loading technology is used to load, parse, call and uninstall the application software.

[0012] Compared with method 1, method 2 has more obvious advantages: first, after the dynamic loading of the new version of the application software fails and returns an error, the operating system can continue to run normally and continue to dynamically load the old version of the application software; second, it can support the functions of online upgrading, solidification and starting the new version of the application software without powering off; finally, the operating system is separated from the application software, which narrows the scope of analysis and location of the fault problem. Of course, there are technical difficulties in implementing method 2, which requires the boot program and the file system supported by the operating system to comply with the unified standard protocol, otherwise interactive access is not possible.

[0013] (3) Dual boot area upgrade and hardening method

[0014] The embedded system image memory is divided into area A and area B with a peer structure. The system boot process is performed alternately from area A and area B. The boot area is swapped each time the system image is upgraded. The area updated by the system image upgrade package is the current non-boot area, that is, when the system is booted from area A, the system image is updated to area B; conversely, when the system is booted from area B, the system image is updated to area A.

[0015] This upgrade solidification method allows the system image to be stored in a double backup in the program memory. If the upgrade process fails, it can be loaded and started from the area where it was successfully started last time, which is robust. However, this method is not suitable for embedded terminals with small external memory or flash memory, because the dual boot area needs to reserve sufficient storage space to ensure that the current and iterative upgrade image data can be stored, which leads to a certain amount of storage waste. Summary of the invention

[0016] 1. Technical issues to be resolved

[0017] The technical problem to be solved by the present invention is how to provide an online upgrade and curing method for dynamically loaded application software on a chip, so as to solve the difficult problems of online upgrade, curing and version rollback of application software.

[0018] (II) Technical solution

[0019] In order to solve the above technical problems, the present invention proposes an online upgrade and curing method for dynamically loading application software on a chip, the method comprising the following steps:

[0020] Step 1: The embedded terminal device is powered on and the general boot program is executed first; the hardware device is initialized and the mapping table of the memory space is established, so as to build the hardware and software environment for the operating system; then the system image data in the flash memory is moved to the memory and the PC pointer jumps to start the operating system;

[0021] Step 2: After the operating system is started, it takes over the embedded terminal device and completes the FTP server initialization and root file system mounting;

[0022] Step 3: The system starts a background task to automatically search whether there is an application software executable file under RFS. If there is, the application software is dynamically loaded, parsed and called for execution; if there is no application software executable file, the user is prompted to upload the application software executable file in the method agreed by the user;

[0023] Step 4: The user sends the pre-upgraded or uploaded application software to the device terminal through FTP instructions, and the system background task is responsible for receiving and parsing the file data into the Application Software address space;

[0024] Step 5: The system background task extracts the valid length data content of the application software from the Application Software address space and writes it into RFS, which is stored as the application software executable file App.dll file with a specific name or version; before writing, if the App.dll file already exists, it is backed up as App.dll.bak, and then the data of the App.dll file is read to obtain the MD5 code, which is compared with the MD5 code stored in the Application Software address space; if the MD5 code data is the same, it means that the application software is uploaded successfully; otherwise, it means that the application software upload fails, and the system background task deletes the App.dll file;

[0025] Step 6: After the application software is successfully uploaded, if the application software is running, the user dynamically unloads the currently running old version of the application software by calling the dynamic loading instruction through the shell, then calls the instruction to dynamically load and parse the new version of the application software App.dll, and calls the execution command to restore the running state of the current application software; if the application software is not running, directly call the dynamic loading instruction to load, parse App.dll and call for execution.

[0026] Further, in step 2, if the embedded terminal does not support the network port, initialize other specific servers.

[0027] Further, the other specific server is RapidIO.

[0028] Further, in step 3, the prompting method is that the operating system background task sends an FTP prompt log file to the host computer, a pop-up window is displayed on the terminal with a graphical interface, the terminal device gives an audible alarm or a light is used to prompt the upload of the application software executable file.

[0029] Further, in step 5, before backup, if the App.dll.bak file already exists, directly delete it.

[0030] Further, when deleting the App.dll file in step 5, if the App.dll.bak file exists, rename it back to App.dll.

[0031] Further, the address spaces that can be normally accessed and operated by the operating system include random access memory RAM and flash memory; a certain size of memory is allocated in the RAM as the Application Software address space for temporarily storing the uploaded application software data; the flash memory is divided into three parts: one part is used to store the general-purpose boot image; one part is used to store the operating system image; the remaining address space is reserved and will be uniformly managed by the root file system RFS after the operating system starts, responsible for adding, deleting, modifying, and querying the application software executable files.

[0032] Further, the general-purpose boot image and the system image are burned into the flash memory at one time with the help of a solidification tool when the hardware device leaves the factory or is delivered.

[0033] Further, add a file header before the application software executable file generated by the host computer, with a total of 32 bytes; among them, bytes 0-3 store the effective length of the application software executable file; bytes 4-15 are reserved for extension space and filled with empty / invalid data; bytes 16-31 store the MD5 checksum of the application software executable file; add 0 at the end of the file to achieve address alignment.

[0034] Furthermore, when the hardware device leaves the factory or is delivered, the manufacturer uses a curing tool to solidify the universal boot and system image at one time, and the user only needs to maintain and upgrade the application software.

[0035] (III) Beneficial effects

[0036] The present invention proposes an online upgrade and curing method for dynamically loading application software on a chip, which separates the operating system from the application software, maximizes the use of on-chip storage without using any external storage device (such as a hard disk, SD card, USB flash drive, etc.) and curing tools (such as JTAG, FlashTool), and effectively solves the problems of online upgrade, curing and version rollback of application software.

[0037] The present invention does not require the use of off-chip storage devices, does not require customized development of universal boot programs, and does not require the use of curing tools. It only relies on on-chip flash memory to help users solve the problems of online upgrading, curing, and version rollback of embedded application software.

[0038] When the present invention is upgraded online, if the new version of application software fails to be dynamically loaded, parsed or called, it can be debugged through instructions without affecting the execution of the embedded operating system; at the same time, the entire upgrade process does not require power off, device removal or borrowing of curing tools, and is completely operated online. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 Address space allocation for the present invention;

[0040] Figure 2 The system image file format of the present invention;

[0041] Figure 3 This is a flow chart of the dynamic loading of application software and online upgrading, curing, and version rollback of the present invention. DETAILED DESCRIPTION

[0042] In order to make the purpose, content and advantages of the present invention more clear, the specific implementation methods of the present invention are further described in detail below in conjunction with the drawings and examples.

[0043] The present invention relates to the field of industrial control, and provides an online upgrade and curing method for application software of an embedded computer with an embedded operating system. The online upgrade and curing method designed by the present invention separates the operating system from the application software, maximizes the use of on-chip storage without using any external storage device (such as a hard disk, SD card, USB flash drive, etc.) and curing tools (such as JTAG, FlashTool), and effectively solves the problem of online upgrade, curing and version rollback of application software.

[0044] The address space size for normal accessible operations of a 32-bit operating system is 4G, which includes random access memory (RAM), flash memory, and other address spaces. RAM is the temporary data storage medium for the boot program, operating system, and other running programs; flash memory is a long-life non-volatile memory with the physical property of retaining data when powered off, and can be used to solidify the boot, system image, and application software programs. The address space distribution defined by the present invention is as shown in Figure 1 shown.

[0045] Apply for a certain amount of memory in RAM as the Application Software address space to temporarily store the uploaded application software data.

[0046] The flash memory is divided into three parts: one part is used to store general-purpose boot images (such as Uboot, BootLoader, and PMON, etc.); one part is used to store the operating system image; the remaining address space is reserved and will be uniformly managed by the Root File System (RFS) after the operating system starts, and is responsible for adding, deleting, modifying, and querying the executable files of the application software. Among them, the general-purpose boot image and the system image can be burned into the flash memory at one time with the help of a solidification tool when the hardware device leaves the factory or is delivered, because users do not need to pay attention to or upgrade the boot program and the operating system.

[0047] Data format of the application software upload file package

[0048] To facilitate the verification of the correctness of the uploaded and solidified application software executable file data, the present invention adds a file header, a total of 32 bytes, before the application software executable file (usually.a,.dll, or.lib file) compiled and generated by the host computer. Among them, bytes 0-3 store the effective length of the application software executable file; bytes 4-15 are reserved for extended space and filled with empty / invalid data; bytes 16-31 store the MD5 checksum of the application software executable file. The file tail can be padded with 0 to achieve address alignment. The final format of the application software executable file uploaded and packaged by the host computer is as shown in Figure 2 shown.

[0049] Core advantages of the online upgrade and solidification method

[0050] Aiming at the advantages and disadvantages existing in the existing upgrade and solidification technologies, the purpose of the present invention is to provide a new online upgrade and solidification method for dynamically loading embedded application software. The present invention does not need to use off-chip storage devices, does not need to customize and develop general-purpose boot programs, does not need to rely on solidification tools, and only relies on on-chip flash memory to help users solve the problems of online upgrade, solidification, and version rollback of embedded application software.

[0051] The present invention is not only applicable to embedded terminals with ample storage space, but also to embedded devices with limited storage space, and even to embedded devices that only use CPU on-chip storage; compared with the "dual boot area" upgrade and curing method, the memory utilization rate is higher.

[0052] Online upgrade and curing method implementation

[0053] When the hardware device leaves the factory or is delivered, the manufacturer uses a curing tool to solidify the universal boot and system image at one time, and the user only needs to maintain and upgrade the application software.

[0054] Step 1: The embedded terminal device is powered on and the general boot program is executed first. The hardware device initialization and the establishment of the mapping table of the memory space are completed, so as to build the hardware and software environment for the operation of the operating system; then the system image data in the flash memory is moved to the memory and the PC pointer jump is completed to start the operating system.

[0055] Step 2: After the operating system is started, it takes over the embedded terminal device and completes the FTP (File Transfer Protocol, which is one of the protocols in the TCP / IP protocol group. It has data verification and data retransmission mechanisms to ensure the correctness of data transmission) server initialization and root file system mounting.

[0056] If the embedded terminal does not support the network port, other specific servers (such as RapidIO) can be initialized.

[0057] Step 3: The system starts a background task to automatically search whether there is an application software executable file under RFS. If there is, the application software is dynamically loaded, parsed and called for execution; if there is no application software executable file, the user is prompted to upload the application software executable file in the method agreed by the user.

[0058] The prompt method can be that the operating system background task sends an FTP prompt log file to the host computer; the terminal that supports the graphical interface can display a pop-up window; the terminal device sounds an alarm or turns on a light to prompt the upload of the application software executable file, etc.

[0059] Step 4: The user can send the pre-upgraded or uploaded application software to the device terminal through FTP instructions, and the system background task is responsible for receiving and parsing the file data into the Application Software address space.

[0060] Step 5: The system background task extracts the effective length data content of the application software from the Application Software address space and writes it into the RFS, storing it as an executable file of the application software with a specific name or version (such as the App.dll file; before writing, if the App.dll file already exists, it will be backed up as App.dll.bak (before backing up, if the App.dll.bak file already exists, it will be directly deleted)), then reads the data of the App.dll file, obtains the MD5 code, and compares it with the MD5 code stored in the Application Software address space (the data at the first address offset of 16 to 31 bytes). The method for obtaining the MD5 code is: after reading the data content of the executable file, the system calls the relevant interface function to calculate the MD5 code. If the MD5 code data is the same, it means that the application software is uploaded successfully; otherwise, it means that the application software upload fails, and the system background task deletes the App.dll file (if the App.dll.bak file exists, it will be renamed back to App.dll).

[0061] Step 6: After the application software is uploaded successfully, if the application software is running, the user can use the shell to call the dynamic loading instruction to dynamically unload the currently running old version of the application software, and then call the instruction to dynamically load, parse the new version of the application software and call the execution command to restore the running state of the current application software; if the application software is not running, directly call the dynamic loading instruction to load, parse the App.dll and call the execution.

[0062] If the dynamic loading, parsing or calling of the new version of the application software fails, it can be debugged through instructions without affecting the execution of the embedded operating system; at the same time, the entire upgrade process does not require power-off, equipment removal or borrowing of solidification tools, and is completely an online operation.

[0063] In summary, an in-chip dynamic loading application software online upgrade and solidification method designed by the present invention maximizes the use of in-chip storage without using any external storage devices and solidification tools, and effectively solves the problems of online upgrade, solidification and version rollback of application software.

[0064] The above is only the preferred implementation manner of the present invention. It should be pointed out that for those of ordinary skill in the art, without departing from the technical principle of the present invention, several improvements and deformations can be made, and these improvements and deformations should also be regarded as the protection scope of the present invention.

Claims

1. An online upgrade and solidification method for in-chip dynamically loading application software, characterized in that, The method includes the following steps: Step 1: Power on the embedded terminal device. First, execute the general bootloader; complete the initialization of hardware devices and the establishment of the mapping table of the memory space, etc., so as to build the software and hardware environment for the operating system to run; then move the system image data in the flash to the memory and complete the PC pointer jump to start the operating system; Step 2: After the operating system starts, take over the embedded terminal device, and at the same time complete the initialization of the FTP server and the mounting of the root file system; Step 3: After the system starts, the background task automatically retrieves whether there is an application software executable file under the RFS. If there is, dynamically load the application software, parse it and call to execute; If there is no application software executable file, prompt the user to upload the application software executable file in a user-agreed manner; Step 4: The user sends the pre-upgraded or uploaded application software to the device terminal in the way of FTP instructions, and the system background task is responsible for receiving and parsing the file data into the ApplicationSoftware address space; Step 5: The system background task extracts the valid length data content of the application software from the ApplicationSoftware address space and writes it into the RFS, and stores it as an application software executable file App.dll file with a specific name or version; before writing, if the App.dll file already exists, back it up as App.dll.bak, then read the data of the App.dll file to obtain the MD5 code, and compare it with the MD5 code stored in the ApplicationSoftware address space; if the MD5 code data is the same, it means that the application software upload is successful; otherwise, it means that the application software upload fails, and the system background task deletes the App.dll file; Step 6: After the application software is successfully uploaded, if the application software is running, the user calls the dynamic loading instruction through the shell to dynamically unload the currently running old version of the application software, and then calls the instruction to dynamically load, parse the new version of the application software App.dll, and call the execution command to restore the running state of the current application software; If the application software is not running, directly call the dynamic loading instruction to load, parse App.dll and call to execute.

2. The in-chip dynamic loading application software online upgrade and solidification method according to claim 1, characterized in that, In the step 2, if the embedded terminal does not support the network port, initialize other specific servers.

3. The online upgrade and solidification method for in-chip dynamically loading application software according to claim 2, characterized in that, The other specific server is RapidIO.

4. The in-chip dynamic loading application software online upgrade and solidification method according to claim 1, characterized in that, In the step 3, the prompting method is that the background task of the operating system sends an FTP prompt log file to the host computer, a pop-up window is displayed on the terminal supporting the graphical interface, the terminal device gives an alarm or a light is turned on to prompt to upload the application software executable file.

5. The in-chip dynamic loading application software online upgrade and solidification method according to claim 1, characterized in that, In the step 5, before backing up, if the App.dll.bak file already exists, directly delete it.

6. The in-chip dynamic loading application software online upgrade and solidification method according to claim 5, characterized in that, When deleting the App.dll file in the step 5, if the App.dll.bak file exists, rename it back to App.dll.

7. The online upgrade and solidification method for in-chip dynamically loaded application software according to any one of claims 1-6, characterized in that The address spaces that the operating system can normally access and operate on include the random access memory RAM and the flash memory; A certain amount of memory is applied in RAM as ApplicationSoftware address space for temporary storage of uploaded application software data; the flash memory is divided into three areas: one part is used to store universal boot images; one part is used to store operating system images; the remaining address space is reserved and will be managed by the root file system RFS after the operating system is started, which is responsible for adding, deleting, modifying and checking application software executable files.

8. The in-chip dynamic loading application software online upgrade and solidification method according to claim 7, characterized in that, The universal boot image and system image are burned into the flash memory at one time with the help of a hardening tool when the hardware device leaves the factory or is delivered.

9. The online upgrade and solidification method for in-chip dynamically loading application software according to claim 7, characterized in that, A file header of 32 bytes is added before the executable file of the application software compiled by the host computer. Among them, bytes 0-3 store the effective length of the executable file of the application software. Bytes 4-15 are reserved for expansion space and filled with empty / invalid data. Bytes 16-31 store the MD5 checksum of the executable file of the application software. 0 is added to the end of the file to achieve address alignment.

10. The in-chip dynamic loading application software online upgrade and solidification method according to claim 8, characterized in that, When the hardware device leaves the factory or is delivered, the manufacturer uses a curing tool to solidify the universal boot and system image at one time, and the user only needs to maintain and upgrade the application software.

Images