Single-MCU embedded software separation and verification method and software upgrading method

Abstract

The invention discloses a single MCU embedded software separation and verification method and a software upgrading method, the method comprises an SRAM and a FLASH memory, the interior of the SRAM and the interior of the FLASH memory are each divided into two independent functional areas, and the two independent functional areas are respectively a legal area and an illegal area; under the framework, software in the legal area is packaged into a static library and is configured and stored in the legal area of the FLASH according to a compiling link principle. According to the single-MCU embedded software separation and verification method, the design process is simplified, construction of a dual-core communication mechanism and complexity of dual-core system upgrading are omitted, the development difficulty is lowered, the development workload is reduced, the whole development process is more economical and efficient, the separation method can be achieved only by relying on a linker configuration file, and the method is easy to implement. The legal region part is cited as a static library, the use mode is the same as that of a common static library, and special processing is not needed.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing, and specifically provides a method for separating and verifying single-MCU embedded software. Background Art

[0002] In the prior art, the legal area software and the illegal area software in the dual-core architecture solution are physically isolated and deployed on two independent microcontrollers (MCUs), namely MCU1 and MCU2. MCU1 is dedicated to running the legal software, which is fixed and cannot be upgraded without authorization, and is responsible for supervising the entire download process to ensure the security and compliance of the software. MCU2 is used to run the illegal software, which can be downloaded without authorization. Data exchange between the two MCUs is carried out through a predefined communication protocol, and each maintains an independent version control and checksum mechanism.

[0003] However, it is obvious that only using the predefined communication protocol cannot clearly separate the legal software and the illegal software in the existing single-MCU system, and further improvement is still needed in terms of software compliance and security. Summary of the Invention

[0004] (I) Technical Problems to be Solved Aiming at the deficiencies of the prior art, the present invention provides a method for separating and verifying single-MCU embedded software, which solves the problems raised in the above background art.

[0005] 1. Technical Method To achieve the above object, the present invention provides the following technical method: a method for separating and verifying single-MCU embedded software, which includes SRAM and FLASH memories. Both the SRAM and the FLASH memory are divided into two independent functional areas, and the two independent functional areas are respectively the legal area and the illegal area. Under this framework, the software in the legal area is encapsulated into a static library and stored in the legal area of the FLASH according to the compilation and linking principles, and is executed in the legal area of the SRAM at the same time. The illegal software is compiled and linked to the illegal area of the FLASH and runs in the illegal area of the SRAM. A legal security interface is defined, which is used to comprehensively control the interaction between the illegal software and the legal software.

[0006] Preferably, the static library includes compiling the source code of the legal part using the gcc compiler to generate object files. This step is completed by executing the command gcc -c <source code file name>. Then, the ar tool is used to archive these object files to build the legal static library. The command is ar rc LegalSoftware.a *.o, where LegalSoftware.a is the name of the legal static library and *.o represents all the generated object files. The static library can ensure that the code in the legal area has a fixed position in the memory, facilitating subsequent data calculations related to the legal area.

[0007] Preferably, the static library link positioning of the legal area includes determining the program space occupancy by analyzing the map file, and performing statistics on FLASH and RAM, and then configuring the ICF file (linker configuration file) to achieve accurate link positioning; The strategy for configuring the ICF file is to use compilation directives to force-link the unused symbols in all.o files in the legal code and accurately locate each.o file to adapt to the changes in the RAM and FLASH areas; To ensure that the libraries used are fully linked into the final application, the KEEP statement needs to be used in the linker configuration file. The linker only retains symbols when the application actually needs them. By specifying the KEEP statement, specific symbols are ensured to be permanently included in the application. The KEEP instruction is not sensitive to the parameter order, so the workflow is simplified by referencing the.a file; For example, to ensure that all objects in the LegalSoftware.a library are retained, add the following instruction to the linker configuration file: keep { object LegalSoftware.a} To fix the position of the legal static library, two regions, ROM_region and RAM_region, and their address ranges need to be defined in the linker configuration file using the define directive, which are used to store the read-only (readonly) and read-write (readwrite) segments of the legal part respectively. Using the "place in" keyword, the object files in the legal static library are mapped to the defined code segments. Using readonly and readwrite to replace the traditional segments such as.text,.rodata,.bss,.data,.default, etc. can reduce the workload and the possibility of omission; The following is an example in a linker configuration file for defining two new regions, LR_ROM_region and LR_RAM_region, and specifying their start and end addresses: define symbol __ICFEDIT_region_ LR_ROM_start__ = 0x00000000; define symbol __ICFEDIT_region_ LR_ROM_end__ = 0x0007FFFF; define symbol __ICFEDIT_region_ LR_RAM_start__ = 0x20000000; define symbol __ICFEDIT_region_ LR_RAM_end__ = 0x200FFFFF; define region LR_ROM_region = mem:[from __ICFEDIT_region_ LR_ROM_start__ to __ICFEDIT_region_ LR_ROM_end__]; define region LR_RAM_region = mem:[from __ICFEDIT_region_ LR_RAM_start__ to __ICFEDIT_region_ LR_RAM_end__]; For example, to place all the read-only data in the Dma.o file into the LR_ROM_region area, use the following instruction: place in LR_ROM_region { readonly object Dma.o}。

[0008] Preferably, the software link positioning of the illegal system area includes that for functions implemented outside the legal static library, a custom section needs to be defined in the source code through specific syntax, such as using @"Func" to mark. In the linker configuration file, a region named FUNC_ROM_region should be defined, and the custom section should be placed at a preset absolute address using the place at address instruction, while ensuring sufficient space intervals between sections, thereby ensuring the independence and security of the key functions in the software part of the illegal system area, and these functions also need to be accurately positioned; The example code is as follows: Function definition in the source code: void Func(void) @".Func"{ / / Function implementation Instructions in the linker configuration file: place at address mem:0x09000000 { readonly section.Func}; To prevent non-static library functions and data in the project from being incorrectly linked to the static library area, specific link ranges must be set for them. In this context, two areas are defined: LNR_ROM_region for storing the read-only segments of non-static libraries, and LNR_RAM_region for storing the read-write segments. The goal is to fix the positions of the segments within these areas rather than precisely specifying specific addresses. For this purpose, the place in instruction should be used to arrange the segments of non-static libraries.

[0009] Preferably, the version control of the legal area software and the illegal area software is carried out independently, and it involves storing the checksum of the legal area software and the binary files of the illegal area software at a predetermined location, and regular integrity checks are required to maintain the integrity of the legal software; The update and maintenance operations of the illegal area software module must be independent of the legal area software module, thereby ensuring the stability and security of the legal area software.

[0010] Preferably, the program checksum and detection to ensure the strict separation of the legal area software and the illegal area software include software identification and verification, and the software identification and verification include calculating checksums, implementing watchdog monitoring, program checksum and detection; In a single MCU system architecture, it is technically feasible to achieve the strict separation of the legal area software and the illegal area software. To ensure that the program in the legal software is not accidentally modified during execution and can detect changes caused by physical effects (such as electromagnetic interference, temperature changes, humidity fluctuations) and deliberate interference, it is crucial to perform error detection regularly. The above strategies such as calculating checksums and implementing watchdog monitoring can guarantee the integrity and running stability of the program.

[0011] Preferably, the program checksum and detection can be achieved by setting the length field and the checksum field at fixed positions in the legal area software and the illegal area software. Subsequently, when generating the executable file, these fields are initialized to the FF value. Then, during the program burning stage, the burning software will calculate and update the actual values of these fields. This is a key component to ensure the effectiveness of the method for separating the legal area software and the illegal area software, and its function is to monitor whether the legal area software has been tampered with during operation; This design brings twofold advantages: First, it allows the verification of the checksum to be independent of the program's execution result and be carried out by an external tool. The specific verification process includes extracting the relevant files of the legal software, calculating its checksum, and comparing it with the preset value. Second, the existence of the length field ensures that when calculating the checksum, only the valid code area of the legal software is considered, excluding the blank parts, thereby reducing the uncertainty introduced by redundant information. This design improves the accuracy and efficiency of checksum detection.

[0012] A method for upgrading a single-MCU embedded software. When updating the product program, this method avoids replacing the static library in the legal area and allows partial upgrading of the FLASH memory of a single microcontroller (MCU). Then, only the software modules in the non-legal area need to be upgraded. After the upgrade, the system can operate normally, ensuring the compatibility and continuity of software upgrading.

[0013] (III) Beneficial effects The present invention provides a method for separating and verifying a single-MCU embedded software, which has the following beneficial effects: (1) Compared with the prior art, the method for separating and verifying a single-MCU embedded software has significant advantages in terms of cost-effectiveness. It simplifies the design process, eliminates the construction of the communication mechanism between dual cores and the complexity of dual-core system upgrading. In addition, this method reduces the development difficulty and the development workload, making the entire development process more economical and efficient.

[0014] (2) For the method for separating and verifying a single-MCU embedded software, the separation method can be achieved only by relying on the linker configuration file. The legal area part is referenced as a static library and is used in the same way as a normal static library without special treatment, with low development difficulty.

[0015] (3) The method for separating and verifying a single-MCU embedded software is based on the linking rules and does not depend on a specific compilation linker, having high generality.

[0016] (4) For the method for separating and verifying a single-MCU embedded software, the software modules in the non-legal area are upgraded independently of the software in the legal area. By only updating the software modules in the non-legal area, the time required for upgrading is significantly reduced, thereby improving the efficiency and reducing the cost of the entire upgrade process.

[0017] (5) For the method for separating and verifying a single-MCU embedded software, the checksum algorithm ensures that only the valid code area of the legal software is considered when calculating the checksum through the length field, excluding the blank parts, thereby reducing the uncertainty brought by redundant information and improving the accuracy and efficiency of checksum detection.

[0018] (6) The method for separating and verifying the single MCU embedded software, the checksum algorithm allows the checksum verification to be independent of the program execution result and can be performed by an external tool. The verification process includes extracting the relevant files of the legal software, calculating its checksum and comparing it with the preset value. Description of the Drawings

[0019] Figure 1 It is a schematic diagram of the principle of the structure of the present invention; Figure 2 It is a schematic diagram of the principle of the legal security interface of the structure of the present invention; Figure 3 It is a schematic diagram of the principle of software upgrade of the structure of the present invention; Figure 4 It is a schematic diagram of the prior art. Detailed Embodiments

[0020] Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of the present invention.

[0021] Referring to Figures 1-4 , a method for separating and verifying a single MCU embedded software, the method includes SRAM and FLASH memories, both the SRAM and the FLASH memory are divided into two independent functional areas, and the two independent functional areas are respectively a legal area and an illegal area; under this framework, the software in the legal area is encapsulated into a static library, and the static library includes compiling the source code of the legal part using the gcc compiler to generate object files, this step is completed by executing the gcc -c <source code file name> command, and then, using the ar tool to archive these object files to build the legal static library, the command is ar rc LegalSoftware.a *.o, where LegalSoftware.a is the name we specified for the legal static library, and *.o represents all the generated object files, and the static library can ensure that the code in the legal area has a fixed position in the memory, facilitating subsequent data calculations related to the legal area; And configure the legal area stored in the FLASH according to the compilation and linking principles, and at the same time execute in the legal area of the SRAM, the static library linking and positioning of the legal area, including determining the program space occupancy by analyzing the map file, and performing statistics on the FLASH and RAM, and then configuring the ICF file (linker configuration file) to achieve accurate linking and positioning, and the strategy for configuring the ICF file is to use compilation instructions to force-link the unused symbols in all.o files in the legal code and accurately position each.o file to adapt to the changes in the RAM and FLASH areas; To ensure that the libraries used are fully linked into the final application, the KEEP statement needs to be utilized in the linker configuration file. The linker only retains symbols when the application actually requires them. By specifying the KEEP statement, certain symbols are ensured to be permanently included in the application. The KEEP directive is not sensitive to the parameter order, so the workflow is simplified by referencing the.a file; For example, to ensure that all objects in the LegalSoftware.a library are retained, add the following directive to the linker configuration file: keep { object LegalSoftware.a} To fix the location of the legal static library, two regions, ROM_region and RAM_region, along with their address ranges, need to be defined in the linker configuration file using the define directive. These are used to store the read-only (readonly) and read-write (readwrite) segments of the legal part respectively. Using the "place in" keyword, the object files in the legal static library are mapped to the defined code segments. Using readonly and readwrite instead of traditional segments such as.text,.rodata,.bss,.data,.default, etc. can reduce the workload and the possibility of omission; The following is an example in a linker configuration file to define two new regions, LR_ROM_region and LR_RAM_region, and specify their start and end addresses: define symbol __ICFEDIT_region_ LR_ROM_start__ = 0x00000000; define symbol __ICFEDIT_region_ LR_ROM_end__ = 0x0007FFFF; define symbol __ICFEDIT_region_ LR_RAM_start__ = 0x20000000; define symbol __ICFEDIT_region_ LR_RAM_end__ = 0x200FFFFF; define region LR_ROM_region = mem:[from __ICFEDIT_region_ LR_ROM_start__ to __ICFEDIT_region_ LR_ROM_end__]; define region LR_RAM_region = mem:[from __ICFEDIT_region_ LR_RAM_start__ to __ICFEDIT_region_ LR_RAM_end__]; For example, to place all the read-only data in the Dma.o file into the LR_ROM_region area, use the following instruction: place in LR_ROM_region { readonly object Dma.o}; Illegally made software is compiled and linked to the illegal area of the FLASH and runs in the illegal area of the SRAM. The link positioning of the illegally made area software, including functions implemented outside the legally made static library, requires defining a custom section in the source code using a specific syntax, such as marking with @"Func". In the linker configuration file, a region named FUNC_ROM_region should be defined, and the custom section should be placed at a preset absolute address using the place at address instruction, while ensuring sufficient space intervals between sections, thereby ensuring the independence and security of the key functions in the illegally made area software part, and these functions also need to be accurately positioned; The sample code is as follows: Function definition in the source code: void Func(void) @".Func"{ / / Function implementation Instruction in the linker configuration file: place at address mem:0x09000000 { readonly section.Func}; To prevent non-static library functions and data in the project from being wrongly linked to the static library area, specific link scopes must be set for them. In this context, two regions are defined: LNR_ROM_region is used to store the read-only (readonly) sections of non-static libraries, and LNR_RAM_region is used to store the read-write (readwrite) sections. The goal is to fix the positions of the sections within these regions rather than precisely specifying to a particular address. For this purpose, the place in instruction should be used to arrange the sections of non-static libraries; Define a legally made security interface, which is used to comprehensively control the interaction between illegally made software and legally made software to ensure that data transmission will not have an adverse impact on the functions of legally made software; The version control of the legal area software and the version control of the non-legal area software are carried out independently, and it involves storing the binary files of the checksum legal area software and the non-legal area software at a predetermined location. Regular integrity checks are required to maintain the integrity of the legal software; the update and maintenance operations of the non-legal area software module must be independent of the legal area software module, thereby ensuring the stability and security of the legal area software; The program checksums and detections that ensure the strict separation of the legal area software and the non-legal area software include software identification and verification. Software identification and verification include calculating checksums, implementing watchdog monitoring, program checksums and detections. In a single MCU system architecture, it is technically feasible to achieve the strict separation of the legal area software and the non-legal area software. To ensure that the program of the legal software is not accidentally modified during execution and can detect changes caused by physical effects (such as electromagnetic interference, temperature changes, humidity fluctuations) and deliberate interference, it is crucial to perform error detection regularly. The above strategies such as calculating checksums and implementing watchdog monitoring can ensure the integrity and running stability of the program.

[0022] The length field and the check field are set at fixed positions in the legal area software and the non-legal area software. Subsequently, when generating the executable file, these fields are initialized to the FF value. Then, during the program burning stage, the burning software will calculate and update the actual values of these fields. This can ensure the key components of the effectiveness of the separation method of the legal area software and the non-legal area software, and its function is to monitor whether the legal area software is tampered with during operation; This design brings two advantages: First, it allows the verification of the checksum to be independent of the execution result of the program and is carried out through external tools. The specific verification process includes extracting the files related to the legal software, calculating its checksum, and comparing it with the preset value. Second, the existence of the length field ensures that when calculating the checksum, only the valid code area of the legal software is considered, excluding the blank part, thereby reducing the uncertainty introduced by redundant information. This design improves the accuracy and efficiency of the checksum detection.

[0023] A software upgrade method for a single MCU embedded software separation and verification method. When updating the product program, this method avoids replacing the static library in the legal area and allows partial upgrade of the FLASH memory of a single microcontroller (MCU); then, only the non-legal area software module needs to be upgraded. After the upgrade, the system can keep running normally, ensuring the compatibility and continuity of the software upgrade.

[0024] It should be noted that in this text, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprising", "including" or any other variation thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not expressly listed, or elements inherent to such process, method, article or device.

[0025] Although the embodiments of the present invention have been shown and described, those of ordinary skill in the art can understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the present invention. The scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A single MCU embedded software separation and verification method, characterized in that: The method includes SRAM and FLASH memory, and divides the SRAM and the FLASH memory into two independent functional areas, and the two independent functional areas are a legal area and an illegal area; In this framework, the software in the legal area is encapsulated into a static library and configured according to the compile and link principle to be stored in the legal area of ​​FLASH and executed in the legal area of ​​SRAM; Non-legal software is compiled and linked to the non-legal area of ​​FLASH and runs in the non-legal area of ​​SRAM; Define a legal security interface that is used to fully control the interaction between non-legal software and legal software.

2. A single MCU embedded software separation and verification method according to claim 1, characterized in that: The static library includes using the gcc compiler to compile the source code of the legal part to generate object files. This step is completed by executing the gcc -c <source code file name> command. Then, these object files are archived using the ar tool to build the legal static library. The command is ar rc LegalSoftware.a *.o, where LegalSoftware.a is the name of the legal static library and *.o represents all generated object files.

3. A single MCU embedded software separation and verification method according to claim 1, characterized in that: The static library link positioning of the legal area includes determining the program space occupancy by analyzing the map file, and performing statistics on FLASH and RAM, and then configuring the ICF file, i.e., the linker configuration file; The strategy for configuring ICF files uses compilation instructions to force linking of unused symbols in all .o files in the legal code, and accurately locates each .o file to adapt to changes in RAM and FLASH areas; The libraries used are fully linked into the final application. By utilizing the KEEP statement in the linker configuration file, the linker retains symbols when they are actually needed by the application. By specifying the KEEP statement, you ensure that specific symbols are permanently included in the application. The KEEP directive is not sensitive to the order of parameters, so the workflow is simplified by referencing .a files.

4. A single MCU embedded software separation and verification method according to claim 1, characterized in that: The non-legal region software link positioning includes, for functions implemented outside the legal static library, defining a custom segment in the source code through a specific syntax, using @".Func" to mark, defining a region named FUNC_ROM_region in the linker configuration file, and using the place at address instruction to place the custom segment at a preset absolute address, while ensuring that there is enough space between the segments; In this context, two regions are defined: LNR_ROM_region is used to store read-only segments of non-static libraries, and LNR_RAM_region is used to store readable and writable segments. The goal is to fix the location of each segment within these regions instead of specifying it to a specific address. For this purpose, the place in directive should be used to arrange the segments of non-static libraries.

5. A single MCU embedded software separation and verification method according to claim 1, characterized in that: Version control of legal area software is conducted independently from version control of non-legal area software, and involves storing checksums and binary files of legal area software and non-legal area software in a predetermined location, and performing regular integrity checks to maintain the integrity of the legal area software; The update and maintenance operations of the non-legal area software modules must be independent of the legal area software modules to ensure the stability and security of the legal area software.

6. A single MCU embedded software separation and verification method according to claim 5, characterized in that: Program verification and testing to ensure strict separation of legal area software and illegal area software includes software identification and verification, which includes calculation verification, implementation of watchdog monitoring, program verification and testing.

7. A program verification and detection method for a single MCU embedded software separation and verification method as claimed in claim 6, characterized in that: The program checksum detection can be achieved by setting the length field and the check field at fixed positions in the legal area software and the illegal area software. When the executable file is subsequently generated, these fields are initialized to FF values. Then, during the program burning stage, the burning software will calculate and update the actual values ​​of these fields.

8. A single MCU embedded software upgrade method, applied to the single MCU embedded software separation and verification method according to any one of claims 1 to 7, characterized in that: This method avoids replacing the legal area static library when updating the product program, and allows partial upgrade of the FLASH memory of a single microcontroller (MCU); Then, only the software modules in the illegal areas need to be upgraded. After the upgrade, the system can maintain normal operation, ensuring the compatibility and continuity of the software upgrade.

Images