Automatic mapping method, device and storage medium for boot loader image array embedding application storage area

Abstract

The application discloses an automatic mapping method and device of a bootloader image array embedded in an application storage area and a storage medium. The method comprises the following steps: obtaining an original image file, parsing the original image file, generating a target array file and a corresponding target header file; adding segment attribute declaration on the object definition corresponding to the target array file to obtain a target array object and put the target array object into a predefined input segment; allocating an independent target flash memory area for the predefined input segment in a link script of an application project; adding the target array file into the application project and compiling and linking to obtain a target code; placing the target array object in the target flash memory area by a linker and placing the target code in a non-overlapping area outside the target flash memory area to generate a unified burning image containing a bootloader and a target application. The application realizes automatic embedding of a bootloader image, improves address mapping reliability and version consistency.

Description

Technical Field

[0001] This invention relates to the field of embedded systems technology, and in particular to an automatic mapping method, apparatus, and storage medium for embedding a bootloader image array into the application storage area. Background Technology

[0002] In existing technologies, embedded product development often employs a dual-project architecture that separates the bootloader (BOOT) and the application (APP). During production release, it is typically necessary to generate separate bootloader and application images, and then use external scripts, flashing tools, or manual merging methods to generate the final flashing file.

[0003] If the merging of the startup loader image and the application image, as well as the address mapping, rely on manual processing, problems such as address offset errors, missing images, and version inconsistencies can easily occur, affecting mass production efficiency and software release reliability.

[0004] In existing technologies, manually merging hexadecimal (HEX) files relies on manual steps, which can easily lead to abnormal file burning due to errors in file path, version, and address parameters; external script splicing and compilation are disconnected, and the script needs to be maintained synchronously after changes in flash memory address and length, and lacks compiler verification; burning the boot loader and application independently increases the production cycle, and if a certain step fails or the version is incompatible, it will cause abnormal device startup.

[0005] Therefore, how to automatically import the bootloader image, automatically bind the specified flash memory area, and automatically participate in the linking process to generate the final burning file during the application project compilation stage is a problem that urgently needs to be solved in this field.

[0006] Therefore, existing technologies still need to be improved and enhanced. Summary of the Invention

[0007] This invention provides an automatic mapping method, apparatus, and storage medium for embedding a bootloader image array into the application storage area. It aims to solve the technical problems in the prior art where the merging, address mapping, and version synchronization of the bootloader image and the application image rely on manual processing or external scripts, resulting in address offsets, version inconsistencies, abnormal burning files, and a lack of compiler verification.

[0008] A first aspect of the present invention provides an automatic mapping method for embedding a bootloader image array into an application storage area, the method comprising: Obtain the original image file, parse the original image file in byte order to obtain image data, and generate a target array file and its corresponding target header file. The target array file contains all the binary data of the startup loader, and the target header file is used to record the length, starting address and check information of the target array file. Add a segment attribute declaration to the object definition corresponding to the target array file to obtain the target array object and put the target array object into the predefined input segment; In the linker script of the application project, an independent target flash memory storage area is allocated for the predefined input segment. The address range of the target flash memory storage area is consistent with the address expected to be occupied by the bootloader, and the predefined input segment is mapped to the target flash memory storage area. The target array file is added to the application project and compiled and linked to obtain the target code, which contains the instruction code and interrupt vector table of the target application. The linker places the target array object in the target flash memory storage area and the target code in a non-overlapping area outside the target flash memory storage area, generating a unified burning image that simultaneously contains the bootloader and the target application.

[0009] A second aspect of the present invention provides an automatic mapping device for embedding a bootloader image array into an application storage area, comprising: The parsing module is used to obtain the original image file, parse the original image file in byte order to obtain image data, and generate a target array file and its corresponding target header file. The target array file contains all the binary data of the startup loader, and the target header file is used to record the length, starting address and verification information of the target array file. An array object construction module is used to add segment attribute declarations to the object definition corresponding to the target array file, obtain the target array object, and put the target array object into a predefined input segment; The storage allocation module is used to allocate an independent target flash memory storage area for the predefined input segment in the linker script of the application project. The address range of the target flash memory storage area is consistent with the address expected to be occupied by the bootloader, and the predefined input segment is mapped to the target flash memory storage area. The compilation module is used to add the target array file to the application project and compile and link it to obtain target code, which includes the instruction code and interrupt vector table of the target application. The storage module is used by the linker to place the target array object in the target flash memory storage area and place the target code in a non-overlapping area outside the target flash memory storage area, generating a unified burning image that simultaneously contains the bootloader and the target application.

[0010] In a third aspect, embodiments of the present invention also provide a computer-readable storage medium storing one or more programs that can be executed by one or more processors to implement the steps of the automatic mapping method for embedding a bootloader image array into the application storage area as described in any of the preceding claims.

[0011] Beneficial effects: Compared with the prior art, the present invention provides an automatic mapping method, apparatus and storage medium for embedding a startup loader image array into the application storage area. The automatic mapping method for embedding a bootloader image array into the application storage area provided by this invention first obtains an original image file, parses the original image file byte-by-byte to obtain image data, and generates a target array file and its corresponding target header file. The target array file contains all the binary data of the bootloader, and the target header file is used to record the length, starting address, and verification information of the target array file. Then, a segment attribute declaration is added to the object definition corresponding to the target array file to obtain a target array object, which is placed into a predefined input segment. Next, in the linker script of the application project, an independent target flash memory storage area is allocated for the predefined input segment. The address range of the target flash memory storage area is consistent with the address expected to be occupied by the bootloader, and the predefined input segment is mapped to the target flash memory storage area. Further, the target array file is added to the application project and compiled and linked to obtain target code. The target code contains the instruction code and interrupt vector table of the target application. Finally, the linker places the target array object in the target flash memory storage area and the target code in a non-overlapping area outside the target flash memory storage area, generating a unified burning image that simultaneously contains the bootloader and the target application. This invention provides users with an automatic mapping method for embedding a bootloader image array into the application storage area. By converting the bootloader image into an array file and adding segment attribute declarations, it is mapped to a specified flash storage area via a linker script. During the compilation and linking of the application project, the linker automatically completes the address allocation and generates a unified burning image. This solves the problems of address offset, version inconsistency, low burning efficiency, and poor reliability caused by manual merging or external script splicing. It achieves the beneficial effects of high automation, reliable address mapping, strong version consistency, suitability for mass production release, and easy over-the-air upgrade. Attached Figure Description

[0012] Figure 1 A flowchart illustrating an embodiment of the automatic mapping method for embedding a bootloader image array into the application storage area provided by the present invention; Figure 2 A flowchart illustrating an embodiment of the automatic mapping method for embedding a startup loader image array into the application storage area provided by the present invention; Figure 3 This is an overall system architecture diagram of an embodiment of the automatic mapping method for embedding a startup loader image array into the application storage area provided by the present invention; Figure 4 A flowchart illustrating the image conversion tool of an embodiment of the automatic mapping method for embedding a startup loader image array into the application storage area provided by the present invention; Figure 5 This is a system general principle block diagram of an embodiment of the automatic mapping device for embedding the startup loader image array into the application storage area provided by the present invention. Detailed Implementation

[0013] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0014] Example 1 The automatic mapping method for embedding the startup loader image array into the application storage area provided in this embodiment can be executed by multiple terminals. The terminals can be, but are not limited to, smart computers, smart mobile devices, or cloud servers / edge gateways, etc. The following description uses a smart computer as an example.

[0015] In the existing embedded product field, especially in automotive electronics, body control, Near Field Communication (NFC) controllers, and other microcontroller unit (MCU) applications, a dual-project architecture with separate BOOT and APP is often adopted to ensure that the system has reliable boot and firmware upgrade capabilities and application integrity verification capabilities. In this dual-project architecture, the bootloader project is responsible for power-on checks, upgrade reception, application integrity judgment, and jump execution, while the application project is responsible for the main business logic. During production release, it is usually necessary to generate bootloader images and application images separately, and then generate the final programming file through merging, splicing, or step-by-step programming.

[0016] In the existing technology, the following solutions are usually adopted to address the problem of integrated distribution of the startup loader and the application.

[0017] First, hexadecimal files are manually merged. Specifically, after compilation, developers manually call a merging tool to combine the hexadecimal files of the startup loader and the application into a single burning file. This approach relies on manual steps, which is prone to errors such as incorrect file path specification, improper version selection, or incorrect address parameter input, leading to burning file anomalies. Furthermore, it is difficult to integrate into automated build processes and is not conducive to stable reproduction in mass production environments.

[0018] Alternatively, fixed addresses can be appended using an external script. Specifically, a batch script or script program appends the binary BIN (Binary File Format) file of the bootloader to a specified offset position in the application image. This approach is isolated from the compilation project. When the flash memory address range, region length, or segment name changes, the script needs to be manually maintained synchronously. Furthermore, it lacks automatic verification by the compiler and linker, and address offset errors are often only discovered after programming.

[0019] Alternatively, the bootloader and application can be programmed separately. Specifically, programming is done in two steps on the production side: first programming the bootloader, then programming the application. This approach increases production cycle time and operational steps, reduces production line efficiency, and if programming fails at any step or the two image versions are incompatible, it can lead to abnormal device startup or functional failure, increasing quality risks.

[0020] It can be seen that existing solutions all share a common technical flaw: the lack of a mechanism to automatically introduce the bootloader image during the application project compilation phase, automatically bind to a specified flash memory region, automatically participate in linking, and generate the final burning file. In existing solutions, the bootloader image always exists as an external, independent file, disconnected from the application project's build process. This results in address mapping, version synchronization, and capacity verification not being automatically completed during the compilation and linking phases, making reliability reliant on manual verification.

[0021] Based on this, this embodiment provides an automatic mapping method for embedding a bootloader image array into the application storage area. This method enables the bootloader image to be automatically converted into an array and used as a source file for the application project during compilation and linking. Through segment attribute declarations and linker script configurations, the linker automatically places the array object of the bootloader in the specified flash storage area and places the application code in a non-overlapping area. This ultimately generates a unified burning image that contains both the bootloader and the application, thereby avoiding manual merging and external script splicing, and improving production efficiency and release reliability.

[0022] like Figure 1 As shown, the automatic mapping method for embedding the bootloader image array into the application storage area provided in this embodiment includes the following steps: S100. Obtain the original image file, parse the original image file in byte order to obtain image data, and generate a target array file and its corresponding target header file. The target array file contains all the binary data of the startup loader, and the target header file is used to record the length, starting address and verification information of the target array file.

[0023] In this embodiment, the original image file is first obtained.

[0024] The original image file is generated when the startup loader project is built using the compilation and linking toolchain of the startup loader project.

[0025] Specifically, refer to Figure 2 , Figure 2This is a flowchart of the automatic mapping method for embedding the bootloader image array into the application storage area according to the present invention. As can be seen, in this embodiment, a bootloader (BOOT) project is first constructed. Developers write the bootloader source code according to the target chip model and boot requirements, including modules such as power-on initialization, hardware detection, upgrade protocol processing, and application jump. After compilation and linking, an executable file of the bootloader is generated, and the original image file is output. The format of the original image file includes Intel HEX (Intel Hexadecimal Object File Format) or BIN. Subsequently, a batch script calls the HexView tool (a hexadecimal file format conversion tool) and uses the / XC command to convert the original image file into an FBL array file (.c file) and its corresponding header file (.h file), while extracting image metadata (including address, length, and checksum). The input segment .FBLProGram is marked on the object definition of the generated FBL (Flash Bootloader) array file. Then, the GNU ld (GNU ld linker script) linker script maps .FBLProGram to the FBLProGramData storage area. Finally, the application (APP) project outputs a unified HEX image that contains both BOOT and APP. During the entire build process, three constraints are set: conversion pre-check, C macro check, and GNU ld capacity check. Among them, the BOOT range is [0x0, 0xEF80], with a capacity of 61,312 bytes; the linker check includes a hard constraint on MEMORY capacity (existing mechanism) and an ASSERT assertion check (enhanced mechanism); the image metadata includes address, length, checksum, and C / H consistency; release consistency is achieved through the unified HEX image, which is suitable for production line burning and OTA (Over-The-Air) release.

[0026] In this embodiment, the invocation of the image conversion tool is triggered by a batch script, which can be configured as part of the application project pre-build step to be executed automatically before each application project compilation.

[0027] Furthermore, referring to Figure 3 , Figure 3 This is a schematic diagram of the system architecture involved in the automatic mapping method of embedding the startup loader image array into the application storage area according to the present invention.

[0028] like Figure 3As shown, the system architecture provided in this embodiment is divided into a bootloader project side and an application project side. The bootloader project side includes a bootloader project (e.g., VINFAST_NFCR_MSPM0G3519_BOOT project) and its Intel HEX (Intel Hexadecimal Object File Format) image output (e.g., ...BOOT.hex), a batch processing trigger module (optionally integrated with the pre-build step), the HexView tool, and the generation of the flash bootloader (FBL) array file (e.g., NFC_PKC_..._FBL.c and its corresponding header file). The application project side includes an application project (containing business code and FBL arrays), a linker script (e.g., device_linker.lds, which defines the mapping from the input segment .FBLProGram to the storage area FBLProGramData), and a unified image output (e.g., ...APP.hex). The target chip's Flash memory automatic layout includes the BOOT image area (address range 0x00000000 to 0x0000EF7F, capacity 61,312 bytes), a 128-byte reserved area (address range 0x0000EF80 to 0x0000EFFF), the APP interrupt vector table and main program area (starting address 0xF000 and following 0xF120), and the parameter and data area (reserved by partition).

[0029] Before parsing the original image file byte-by-byte to obtain the image data, the process also includes: Calculate the effective data length of the original image file. If the effective data length is greater than the capacity of the target flash memory storage area, terminate the process and return an error status.

[0030] Specifically, before reading the original image file, the image conversion tool first performs a length pre-check on the original image file.

[0031] Specifically, the image conversion tool calculates the effective data length of the original image file, that is, it parses out the actual number of bytes occupied by the defined data in the original image file, and performs alignment processing according to a preset alignment value (such as 256 bytes) to obtain the aligned effective data length. If the effective data length is greater than the capacity of the target flash memory storage area, the image conversion tool immediately terminates the process and returns an error status, without performing subsequent array file generation operations to avoid generating an invalid array file.

[0032] This length pre-check step serves as the first line of defense, ensuring that the original image file is compatible with the target flash memory storage area in terms of data size, preventing the bootloader image from being too large to embed.

[0033] The process of obtaining the original image file, parsing the original image file byte-by-byte to obtain image data, and generating a target array file and its corresponding target header file includes: Read the original image file, parse each record in the original image file in address order, and restore the byte data; The address range of undefined data in the original image file is filled with a preset padding value to obtain continuous byte data; The continuous byte data is output in hexadecimal byte form as the target array file in C language format, and a header file is generated that records the length, starting address and check information of the target array file.

[0034] Specifically, after length pre-check, refer to Figure 4 , Figure 4 This is a schematic diagram of the processing flow of the image conversion tool.

[0035] like Figure 4 As shown, the processing flow of the image conversion tool includes: First, receiving the original image file output by the startup loader project, wherein the original image file is in Intel HEX format; Second, parsing the address, sequentially reading the data record and extended address record in the HEX file, and restoring the byte data in address order; Third, selecting and filling the area, using the address range of the target flash memory storage area as the processing range, and filling the addresses of undefined data within the range with 0xFF; Fourth, generating a C / H file, outputting the filled continuous byte data as a target array file in the form of a 0xXX byte array, and generating a target header file that records the array length and checksum.

[0036] The image conversion tool reads the original image file, parses each record in the original image file in address order, and restores the byte data. In this embodiment, the original image file can be an Intel HEX format file. The image conversion tool (e.g., HexView.exe) sequentially parses the extended address records and data records in the HEX file, and restores the data bytes to the corresponding address positions according to the address fields of each record, thereby obtaining a complete address-data mapping relationship. In another optional embodiment, the original image file is a BIN (Binary File Format) format file. The image conversion tool directly reads the byte data in file offset order and maps it byte by byte to the corresponding address starting from the address.

[0037] The address ranges of undefined data in the original image file are filled with a preset padding value to obtain continuous byte data. Specifically, the address ranges of the target flash memory storage area are continuous, but the original image file typically only defines valid data at some addresses, while the remaining addresses are not defined in the original image file. To obtain continuous byte data that completely covers the entire target flash memory storage area, the image conversion tool traverses all addresses of the target flash memory storage area, writing the corresponding restored bytes to addresses with defined data and writing the preset padding value to addresses with undefined data. In this embodiment, the preset padding value is the erase state value of the flash memory, i.e., 0xFF, to ensure that the filled area is in a known state after programming.

[0038] In one specific embodiment, the image conversion tool uses the HexView tool, which uses target command-line instructions to limit the address range of the original image file, fill holes, and output C arrays.

[0039] The target command is: ; The / AR instruction limits the address range to be processed (including the start and end addresses), the / FR instruction creates a complete region and uses the / FP instruction to specify the filling mode, filling all addresses of undefined data within the range with 0xFF, and the / XC instruction outputs the filled consecutive byte data as a source file in C language array format.

[0040] In this embodiment, the image conversion tool first performs a length pre-check on the original image file. After passing the check, the processing result is output to a temporary file. After the check passes, the file is replaced in pairs with the target array file and its corresponding target header file to avoid the original valid file being incorrectly overwritten due to conversion failure.

[0041] The continuous byte data is output in hexadecimal byte format as a target array file in C language format, such as a .c file, and a corresponding target header file, such as a .h file, is generated. The target header file records the length, starting address, and checksum information of the target array file. A byte array variable is defined in the target array file. Each element of the byte array variable corresponds sequentially to the byte data at each address in the target flash memory storage area, including the valid data and the padding data. The length of the array is equal to the capacity of the target flash memory storage area or the actual number of bytes of the continuous byte data. The header file records the length of the target array file (i.e., the number of array elements, defined as a macro constant, such as _BLOCK0_LENGTH), the starting address (i.e., the expected starting address of the flash memory for the bootloader, defined as a macro constant, such as _BLOCK0_ADDRESS), and checksum information (e.g., the 16-bit cumulative sum of the continuous byte data, defined as a macro constant, such as _BLOCK0_CHECKSUM). The target array file and the header file together constitute an array representation of the startup loader image, wherein the target array file carries the actual data, and the header file provides data attribute information for the application project.

[0042] Furthermore, in this embodiment, the target header file contains a consistency check macro, and the target array file contains a check statement corresponding to the consistency check macro. When the versions of the target header file and the target array file are inconsistent, the check statement triggers a compilation error.

[0043] Specifically, when generating the target header file, the image conversion tool randomly generates a target check value macro (e.g., _GEN_RAND) and writes the target check value into the target header file; at the same time, when generating the target array file, it writes a consistency check statement in the target array file that is equal to the consistency check macro value in the target header file.

[0044] Since the target header file and the target array file are generated from the same conversion process, their checksums must be equal. If, during subsequent development, only one file is replaced without simultaneously replacing the other, the checksum will not match the macro value, triggering an error and terminating the compilation phase. This avoids silent errors caused by file version mismatches. This mechanism ensures that the target header file and the target array file always originate from the same conversion process, maintaining data consistency and traceability.

[0045] In one embodiment, the code snippet of the target array file is illustrated as follows:

[0046] The corresponding code snippet for the target header file is shown below:

[0047] As can be seen, the target header file contains consistency check macros (_GEN_RAND), block count macros (_NUMBLOCKS), start address macros (_BLOCK0_ADDRESS), length macros (_BLOCK0_LENGTH), and checksum macros (_BLOCK0_CHECKSUM). The target array file contains check statements corresponding to the consistency check macros; when the versions of the target header file and the target array file are inconsistent, these check statements trigger compilation errors. The target array file adds segment attribute modifiers at the array variable definitions, classifying the array variables into predefined input segments.

[0048] S200: Add a segment attribute declaration to the object definition corresponding to the target array file to obtain the target array object and put the target array object into the predefined input segment.

[0049] Add a segment attribute declaration to the object definition corresponding to the target array file to obtain the target array object, including: Add a compiler-supported segment attribute modifier to the array variable definition in the target array file. The segment attribute modifier is used to place the array variable into the target input segment. The target input segment is used to collect data objects with the segment attribute declaration during the compilation stage so that the linker script can map the data objects to the target flash memory storage area. The target input segment is preserved in the linker script of the application project via the KEEP directive to prevent the linker from deleting the target array object when the garbage collection option is enabled.

[0050] In this embodiment, a compiler-supported segment attribute modifier is added to the array variable definition in the target array file.

[0051] Specifically, the segment attribute modifier is the `__attribute__((section(".FBLProGram")))` syntax supported by the GCC (GNU Compiler Collection) compiler. Here, `__attribute__` is the extended attribute mechanism of the GCC compiler, and `section(".FBLProGram")` specifies that the array variable should be placed in the target input segment named `.FBLProGram`. In another alternative embodiment, the segment attribute modifier can also be implemented through macro encapsulation. For example, the macro `V_MEMROM0` can be defined as `__attribute__((section(".FBLProGram")))`, and used at the array variable definition using `V_MEMROM0 unsigned char Blk0[_BLOCK0_LENGTH]={...}`, making the code more concise and easier to maintain.

[0052] The segment attribute modifier is used to place the array variable into the target input segment, which in this embodiment can be the .FBLProGram segment. The target input segment is used to collect data objects with the segment attribute declaration during the compilation phase, so that the subsequent linker script can map the data objects to the target flash memory storage area.

[0053] When compiling the target array file, the compiler categorizes the array variables into the target input segment based on the segment attribute modifier, rather than the default data segment (e.g., the .data segment) or read-only data segment (e.g., the .rodat segment), thus giving the array variables an independent segment identifier in the compiled target file. During subsequent linking stages, when reading each target file, the linker can identify the data objects belonging to the target input segment based on the segment identifier and process them uniformly according to the linker script's mapping rules.

[0054] Furthermore, the target input segment is preserved in the linker script of the application project using the KEEP directive to prevent the linker from deleting the target array object when garbage collection options are enabled. Specifically, the linker typically supports garbage collection options during the linking process (e.g., the --gc-sections option in the GCC toolchain). The purpose of these garbage collection options is to scan the referenced segments in the final executable file and automatically delete segments that are not explicitly referenced by any code, thereby reducing the size of the final image.

[0055] Since the bootloader array object is typically placed only as raw data in the starting area of ​​Flash, application code generally does not explicitly read or reference the contents of this array at runtime. In other words, the bootloader is executed directly by hardware after chip reset, not by application code. Therefore, with garbage collection enabled, the target array object may be considered unreferenced and deleted by the linker, resulting in missing bootloader data in the final burned image. To overcome this problem, in this embodiment, the target input segment is explicitly reserved in the linker script using the KEEP instruction. Specifically, in the SECTIONS (segment mapping) command of the linker script, the KEEP instruction is used to explicitly reserve the target input segment. (.FBLProGram The `KEEP` directive, or similar, instructs the linker to retain the segment and all its contained data objects regardless of whether the segment is explicitly referenced, and not to garbage collect them. The `KEEP` directive ensures that the target array object always exists in the final generated image script file.

[0056] In this embodiment, the linker script also defines an output segment corresponding to the target input segment, such as defining a .boot_data_section output segment. The target input segment .FBLProGram is placed into the script output segment, and the script output segment is allocated to the target flash memory storage area, such as the FBLProGramData area, thereby realizing a complete chain from segment attribute declaration to linker script mapping.

[0057] Furthermore, in this embodiment, the script output segment is not modified with NOLOAD, therefore the content of the script output segment is included in the ELF (Executable and Linkable Format) / HEX loadable image, ensuring that the segment data is written to the target flash memory during burning. Through the combination of the above segment attribute declaration and KEEP retention, the target array object is completely preserved and placed at the specified address throughout the entire process of compilation, linking, and final image output, and will not be removed due to optimization options.

[0058] S300. In the linker script of the application project, an independent target flash memory storage area is allocated for the predefined input segment. The address range of the target flash memory storage area is consistent with the address expected to be occupied by the bootloader. The predefined input segment is then mapped to the target flash memory storage area.

[0059] The linking script includes a capacity check instruction, which is used to cause the linking operation to fail and output an error message when the size of the target array object exceeds the capacity of the target flash memory storage area.

[0060] The starting address of the target flash memory storage area is the address at which the hardware reads vector table data from the starting address of the program flash memory after the target chip is reset. The target array object contains at least vector table data and startup code. The target array object is placed in the target flash memory storage area, and the target flash memory storage area contains the starting address, so that the target chip reads vector table data from the starting address and executes the startup loading program after being reset.

[0061] Specifically, the memory layout of the target chip is defined in the linker script of the application project (e.g., GNU ld linker script, file extension .lds), and a separate target flash memory storage area is allocated for the bootloader through the MEMORY command.

[0062] In one embodiment, the core configuration code in the GNU ld linker script that implements the definition and mapping of the bootloader storage area through the MEMORY and SECTIONS commands can be: ; The GNU ld linker script defines the target flash memory storage area FBLProGramData using the MEMORY command, with a starting address of 0x00000000, a capacity of 0x0000EF80 bytes (i.e., 61,312 bytes), and an attribute of readable and executable (RX). It also defines the application interrupt vector table area FLASH1, with a starting address of 0x0000F000 and a capacity of 0x00000100 bytes; and the application main program area FLASH, with a starting address of 0x0000F120 and a capacity of 0x000706E0 bytes. The linker script defines the output segment .boot_data_section using the SECTIONS command, reserves a predefined input segment using KEEP((.FBLProGram)), and allocates this output segment to the FBLProGramData storage area. The address range of the target flash memory storage area is consistent with the address expected to be occupied by the bootloader, that is, a continuous range starting from the starting address of the Flash of the target chip, so as to adapt to the hardware boot mechanism of the target chip to take the vector from the starting address and execute the bootloader after reset.

[0063] Through the above MEMORY definition and SECTIONS mapping, the linker automatically places the target array object with the segment attribute declaration at the starting address of the target flash memory storage area when performing the linking operation, without the need to manually specify the address offset or use external scripts for concatenation.

[0064] In this embodiment, the linker script preserves the predefined input segment (e.g., KEEP((.FBLProGram))) using the KEEP instruction to ensure that the target array object is not deleted by the linker when garbage collection options (e.g., --gc-sections) are enabled, even if it is not explicitly referenced by the application code. Furthermore, the output segment is not modified with NOLOAD, therefore its contents are included in the final generated ELF / HEX loadable image, ensuring that the output segment data is written to the target flash memory during programming.

[0065] Furthermore, the linker script includes a capacity check instruction. This instruction causes the linking operation to fail and outputs an error message when the size of the target array object exceeds the capacity of the target flash memory storage area. Specifically, the linker script performs capacity checks using the ASSERT instruction (assertion instruction). For example, an assertion statement of the form "ASSERT(SIZEOF(.boot_data_section)<= LENGTH(FBLProGramData), "E_BOOT_IMAGE_TOO_LARGE")" can be written. Here, SIZEOF(.boot_data_section) obtains the actual size of the output section, and LENGTH(FBLProGramData) obtains the capacity of the target flash memory storage area. The ASSERT instruction triggers an assertion failure when the actual size of the output section exceeds the capacity of the target flash memory storage area, causing the linking operation to terminate and outputting a customized error message. In addition, the MEMORY definition in the linker script itself provides a hard capacity constraint: when the linker attempts to allocate the output section to the target flash memory storage area, if the size of the section exceeds the LENGTH (length) defined in the MEMORY command, the linker will automatically report an overflow error. With the dual protection of the capacity check instruction and MEMORY capacity constraint, any out-of-bounds situation that causes the target array object to exceed the capacity of the target flash memory storage area will be blocked during the linking stage, ensuring that the target array object will not overflow into the flash memory area where the subsequent application code is located, thus avoiding overwriting the application code or vector table.

[0066] The starting address of the target flash memory storage area is the address at which the hardware reads vector table data from the starting address of the program flash memory after the target chip is reset. The target array object contains at least vector table data and startup code. The target array object is placed in the target flash memory storage area, and the target flash memory storage area contains the starting address, so that the target chip reads vector table data from the starting address and executes the startup loader after reset. After the target chip is reset, the hardware logic automatically reads the first word from the starting address of the program flash memory as the initial value of the stack pointer, reads the second word as the reset vector address (i.e., the address of the first instruction after reset), and then jumps to the reset vector address to start executing the code. Since the starting address of the target flash memory storage area is the same as the starting address of the program flash memory (e.g., 0x00000000), and the target array object is placed in the target flash memory storage area, the vector table data of the startup loader is exactly located at the address where the hardware reads the vector table after the chip is reset. When the target chip is powered on or reset, the hardware reads the vector table data from the starting address, obtains the stack pointer and reset vector of the bootloader, and jumps to the entry address of the bootloader to execute the bootloader. The bootloader then completes subsequent operations such as system initialization, application integrity verification, and jump.

[0067] As can be seen, in this embodiment, the build phase includes a three-layer checking mechanism. The first layer is a pre-conversion length check: the image conversion tool calculates the effective data length of the original image file (aligned to 256 bytes). If it exceeds the target flash memory storage capacity (0xEF80 bytes), the conversion is terminated and a non-zero exit code is returned. The second layer is a C compilation assertion check: through the C99 standard typedef compile-time assertion mechanism, a declaration is given in the target array file. When the startup loader image length exceeds the storage capacity, a compilation error is triggered. The third layer is a GNU ld capacity check: the linker script uses a MEMORY capacity hard constraint and the ASSERT instruction to make the final decision. If either check fails, the linking process terminates and an error message is output.

[0068] Furthermore, this embodiment also includes a capacity overflow check verification. Specifically, the size of the target array object is set to exceed the target flash memory storage capacity by 1 byte, i.e., the target array object size is 0xEF81 bytes and the target flash memory storage capacity is 0xEF80 bytes. The compilation phase passes, but the linking phase fails. The linker outputs a MEMORY capacity overflow error and an ASSERT custom error message, and the build process is blocked. This verification result shows that regardless of the tool used to generate the target array object, as long as its final size exceeds the target flash memory storage capacity, the capacity check mechanism in the linking phase can block the build, preventing the out-of-bounds image from being incorrectly released.

[0069] In one embodiment, the actual command output for capacity out-of-bounds check verification can be: .

[0070] S400. Add the target array file to the application project and compile and link it to obtain the target code, which includes the instruction code and interrupt vector table of the target application.

[0071] Add the target array file to the application project and compile and link it to obtain the target code, including: The target array file is used as a source file in the application project for compilation, and the compiler compiles the target array object into an object file. The linker reads the linker script of the application project, and allocates physical addresses on the target chip to each code segment and data segment according to the memory area addresses and segment mapping rules defined in the linker script, thereby generating the executable target code.

[0072] Specifically, the target array file and its corresponding header file are added to the source code directory of the application project as one of the source files of the application project, and used as input materials for subsequent compilation.

[0073] When compiling the application project, the compiler reads the segment attribute declarations already added to the target array file, and according to the segment attribute declarations, classifies the target array object into a predefined input segment, generating a target file containing the input segment and its data; at the same time, the compiler compiles the other source files of the application into corresponding target files.

[0074] Then, the linker reads the linker script of the application project. Based on the storage area addresses and segment mapping rules defined in the linker script, it merges the code and data belonging to each input segment in each object file into corresponding output segments and assigns physical addresses on the target chip to each output segment. Specifically, the target array objects belonging to the predefined input segments are allocated to the target flash memory storage area (i.e., the starting address of the hardware read vector table after chip reset) according to the linker script's mapping rules. The application's instruction code and interrupt vector table are allocated to a subsequent flash memory area outside the target flash memory storage area (e.g., the FLASH area starting at address 0x0000F000), ensuring that they do not overlap with the bootloader data in terms of physical address, forming a complete address layout. The linker outputs executable object code, which includes the bootloader data, the application's instruction code, and the interrupt vector table. At this point, the bootloader data and application data have completed address binding during the linking stage, forming an ordered, unified executable image within the same address space. Subsequent format conversion is all that's needed to generate a unified image file suitable for burning.

[0075] S500: The linker places the target array object in the target flash memory storage area and places the target code in a non-overlapping area outside the target flash memory storage area, generating a unified burning image that simultaneously contains the bootloader and the target application.

[0076] Specifically, during the linking process, the linker allocates the target array object belonging to the predefined input segment to the target flash memory storage area (i.e., the starting address of the hardware read vector table after chip reset) according to the storage area address and segment mapping rules defined in the linker script, and allocates the application's instruction code and interrupt vector table to subsequent flash memory areas outside the target flash memory storage area.

[0077] In this embodiment, the address range of the target flash memory storage area is 0x00000000 to 0x0000EF7F. The target array object is placed within this address range, and the target code, which includes application instruction code and an interrupt vector table, is placed in the subsequent flash memory area starting at address 0x0000F000. The target flash memory storage area and the subsequent flash memory area are contiguous in address space but do not overlap, thereby ensuring that the bootloader data and application code are physically independent and do not encroach on each other's space.

[0078] Then, a unified burning image containing both the bootloader and the target application is generated. Specifically, after the linker outputs executable target code (e.g., an ELF format file), a format conversion tool converts the target code into a unified image file suitable for burning.

[0079] In this embodiment, the unified burning image is a HEX format file or a BIN format file. Since the target array object has been allocated to the starting address of the target flash memory storage area during the linking stage, and the application portion of the target code is allocated to subsequent non-overlapping flash memory areas, the unified burning image naturally contains all the binary data of the bootloader (located in the starting address range of the image file) and all the instruction code and interrupt vector table of the target application (located in the subsequent address range of the image file), without the need for any external tools for secondary merging or manual offset splicing.

[0080] Ultimately, the bootloader data, as an object segment of the application project, is automatically written to a fixed flash memory address by the linker during the compilation and linking phase, eliminating the need for manual offsetting and splicing. The unified programming image can be directly used for programming the target chip: when the unified programming image is programmed to the target chip, upon target chip reset, the hardware automatically reads the vector table data from the flash memory start address (i.e., the start address of the target flash memory storage area) to obtain the initial value of the bootloader's stack pointer and the reset vector address, and then jumps to the bootloader's entry address to begin execution. After completing system initialization and application integrity verification, the bootloader jumps to the application's entry address in the subsequent flash memory area to execute the target application's business logic.

[0081] The unified flashing image is used for mass production flashing. Specifically, the production end only needs to use the unified flashing image for a single flashing operation to simultaneously deploy the bootloader and application, eliminating the need for step-by-step flashing. In more embodiments, the unified flashing image is also used for over-the-air (OTA) updates, released as a complete upgrade package. During the upgrade process, reliable recovery or re-flashing of the bootloader is achieved through a fixed flash memory area. All the above embodiments are based on the automatic generation of the final flashing file, with the linker automatically completing address allocation and capacity checks during the build phase, requiring no manual intervention.

[0082] Furthermore, in this embodiment, it also includes: When the startup loader project is updated, the steps of building the startup loader project and generating the original image file are re-executed, and the steps of obtaining the original image file, parsing the original image file in byte order to obtain image data, and generating the target array file and its corresponding target header file are re-executed, so as to generate a new target array file corresponding to the updated startup loader project; After replacing the original target array file in the application project with the new target array file, the compilation and linking steps are re-executed to complete the synchronous embedding of the startup loader image.

[0083] Specifically, during development iterations, if the source code of the bootloader changes (e.g., fixing upgrade protocol vulnerabilities, adding support for new hardware, or adjusting boot timing), the bootloader project needs to be recompiled to generate a new original image file. At this time, the image conversion tool rereads the new original image file and regenerates a new target array file and its corresponding target header file. The application project developer only needs to replace the original files in the project with the new target array file and its header file; manual copying or version verification is unnecessary. Since the consistency check macros contained in the target header file are updated upon regeneration, and the check statements in the target array file are synchronized, any version mismatch caused by incomplete file replacement will be immediately detected and reported during the compilation phase. After replacement, the application project is recompiled and linked, and the new target array object is placed in the target flash memory storage area by the linker, completing the update and embedding of the bootloader image. The entire process requires no manual merging of image files, no manual modification of address offsets, and no reliance on external scripts for splicing; it can be completed simply by replacing and recompiling the project files, avoiding the risks of manual copying and version mismatch.

[0084] In summary, this embodiment provides an automatic mapping method for embedding a bootloader image array into the application storage area. First, the original image file is obtained, and the image data is parsed byte-by-byte to generate a target array file and its corresponding target header file. The target array file contains all the binary data of the bootloader, and the target header file records the length, starting address, and verification information of the target array file. Then, a segment attribute declaration is added to the object definition corresponding to the target array file to obtain the target array object, which is then placed into a predefined input segment. Finally, in the linker script of the application project, for... The predefined input segment is allocated an independent target flash memory storage area. The address range of the target flash memory storage area is consistent with the address expected to be occupied by the bootloader. The predefined input segment is mapped to the target flash memory storage area. Further, the target array file is added to the application project and compiled and linked to obtain target code. The target code contains the instruction code and interrupt vector table of the target application. Finally, the linker places the target array object in the target flash memory storage area and the target code in a non-overlapping area outside the target flash memory storage area, generating a unified burning image that simultaneously contains the bootloader and the target application. This embodiment provides users with an automatic mapping method for embedding a bootloader image array into the application storage area. By converting the bootloader image into an array file and adding segment attribute declarations, it is mapped to a specified flash memory storage area by the linker script. During the compilation and linking of the application project, the linker automatically completes the address allocation and generates a unified burning image. This solves the problems of address offset, version inconsistency, low burning efficiency, and poor reliability caused by existing manual merging or external script splicing. It achieves the beneficial effects of high automation, reliable address mapping, strong version consistency, suitability for mass production release, and ease of over-the-air upgrade.

[0085] It should be understood that although the steps in the flowcharts shown in the accompanying drawings are displayed sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of the steps in this invention, and these steps can be executed in other orders. Moreover, at least a portion of the steps in this invention may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0086] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program using signal-related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), Synchlink, DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0087] Example 2 Based on the above embodiments, the present invention also provides an automatic mapping device for embedding a bootloader image array into the application storage area, such as... Figure 5 As shown, the automatic mapping device for embedding the bootloader image array into the application storage area includes: The parsing module is used to obtain the original image file, parse the original image file in byte order to obtain image data, and generate a target array file and its corresponding target header file. The target array file contains all the binary data of the startup loader, and the target header file is used to record the length, starting address and verification information of the target array file, as described in Embodiment 1. The array object construction module is used to add segment attribute declarations to the object definition corresponding to the target array file, obtain the target array object, and put the target array object into a predefined input segment, as described in Example 1. The storage allocation module is used to allocate an independent target flash memory storage area for the predefined input segment in the linker script of the application project. The address range of the target flash memory storage area is consistent with the address expected to be occupied by the bootloader. The module also maps the predefined input segment to the target flash memory storage area, as described in Embodiment 1. The compilation module is used to add the target array file to the application project and compile and link it to obtain target code. The target code includes the instruction code and interrupt vector table of the target application, as described in Embodiment 1. The storage module is used by the linker to place the target array object in the target flash memory storage area and place the target code in a non-overlapping area outside the target flash memory storage area, generating a unified burning image that simultaneously contains the bootloader and the target application, as described in Embodiment 1.

[0088] Example 3 The present invention also provides a computer-readable storage medium storing one or more programs that can be executed by one or more processors to implement the steps of the automatic mapping method for embedding a bootloader image array into the application storage area as described above.

[0089] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An automatic mapping method for embedding a bootloader image array into the application storage area, characterized in that, The method includes: Obtain the original image file, parse the original image file in byte order to obtain image data, and generate a target array file and its corresponding target header file. The target array file contains all the binary data of the startup loader, and the target header file is used to record the length, starting address and check information of the target array file. Add a segment attribute declaration to the object definition corresponding to the target array file to obtain the target array object and put the target array object into the predefined input segment; In the linker script of the application project, an independent target flash memory storage area is allocated for the predefined input segment. The address range of the target flash memory storage area is consistent with the address expected to be occupied by the bootloader, and the predefined input segment is mapped to the target flash memory storage area. The target array file is added to the application project and compiled and linked to obtain the target code, which contains the instruction code and interrupt vector table of the target application. The linker places the target array object in the target flash memory storage area and the target code in a non-overlapping area outside the target flash memory storage area, generating a unified burning image that simultaneously contains the bootloader and the target application.

2. The automatic mapping method for embedding the bootloader image array into the application storage area according to claim 1, characterized in that, Before reading the original image file, the process also includes: Calculate the effective data length of the original image file. If the effective data length is greater than the capacity of the target flash memory storage area, terminate the process and return an error status.

3. The automatic mapping method for embedding the bootloader image array into the application storage area according to claim 1, characterized in that, The process of obtaining the original image file, parsing the original image file byte-by-byte to obtain image data, and generating a target array file and its corresponding target header file includes: Read the original image file, parse each record in the original image file in address order, and restore the byte data; The address range of undefined data in the original image file is filled with a preset padding value to obtain continuous byte data; The continuous byte data is output in hexadecimal byte form as the target array file in C language format, and a header file is generated that records the length, starting address and check information of the target array file.

4. The automatic mapping method for embedding the bootloader image array into the application storage area according to claim 1, characterized in that, The target header file contains a consistency check macro, and the target array file contains a check statement corresponding to the consistency check macro. When the versions of the target header file and the target array file are inconsistent, the check statement triggers a compilation error.

5. The automatic mapping method for embedding the bootloader image array into the application storage area according to claim 1, characterized in that, Add a segment attribute declaration to the object definition corresponding to the target array file to obtain the target array object, including: Add a compiler-supported segment attribute modifier to the array variable definition in the target array file. The segment attribute modifier is used to place the array variable into the target input segment. The target input segment is used to collect data objects with the segment attribute declaration during the compilation stage so that the linker script can map the data objects to the target flash memory storage area. The target input segment is preserved in the linker script of the application project via the KEEP directive to prevent the linker from deleting the target array object when the garbage collection option is enabled.

6. The automatic mapping method for embedding the bootloader image array into the application storage area according to claim 1, characterized in that, The linking script includes a capacity check instruction, which is used to cause the linking operation to fail and output an error message when the size of the target array object exceeds the capacity of the target flash memory storage area.

7. The automatic mapping method for embedding the bootloader image array into the application storage area according to claim 1, characterized in that, The starting address of the target flash memory storage area is the address at which the hardware reads vector table data from the starting address of the program flash memory after the target chip is reset. The target array object contains at least vector table data and startup code. The target array object is placed in the target flash memory storage area, and the target flash memory storage area contains the starting address, so that the target chip reads vector table data from the starting address and executes the startup loading program after being reset.

8. The automatic mapping method for embedding the bootloader image array into the application storage area according to claim 5, characterized in that, Add the target array file to the application project and compile and link it to obtain the target code, including: The target array file is used as a source file in the application project for compilation, and the compiler compiles the target array object into an object file. The linker reads the linker script of the application project, and allocates physical addresses on the target chip to each code segment and data segment according to the memory area addresses and segment mapping rules defined in the linker script, thereby generating the executable target code.

9. An automatic mapping device for embedding a bootloader image array into an application storage area, characterized in that, include: The parsing module is used to obtain the original image file, parse the original image file in byte order to obtain image data, and generate a target array file and its corresponding target header file. The target array file contains all the binary data of the startup loader, and the target header file is used to record the length, starting address and verification information of the target array file. An array object construction module is used to add segment attribute declarations to the object definition corresponding to the target array file, obtain the target array object, and put the target array object into a predefined input segment; The storage allocation module is used to allocate an independent target flash memory storage area for the predefined input segment in the linker script of the application project. The address range of the target flash memory storage area is consistent with the address expected to be occupied by the bootloader, and the predefined input segment is mapped to the target flash memory storage area. The compilation module is used to add the target array file to the application project and compile and link it to obtain target code, which includes the instruction code and interrupt vector table of the target application. The storage module is used by the linker to place the target array object in the target flash memory storage area and place the target code in a non-overlapping area outside the target flash memory storage area, generating a unified burning image that simultaneously contains the bootloader and the target application.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs that can be executed by one or more processors to implement the steps of the automatic mapping method for embedding a bootloader image array into an application storage area as described in any one of claims 1-8.

Images