A method and device for collaborative generation of DSP multi-module BIN files

Abstract

The application discloses a kind of collaborative generation method and device of DSP multi-module BIN file, belong to embedded generation field.Method includes: according to the module generation command and corresponding file of user input, task analysis and scheduling are carried out, and the corresponding task generation instruction is obtained;The memory running layout of DSP link script is parsed, and according to the address mapping table obtained by parsing, the file header and segment header of COFF file are effectively filtered and address repositioned, to obtain code class BIN file;According to the pre-defined parameter offset and check algorithm, the configuration file in text format is sequentially parameter analyzed and format converted, to obtain configuration class BIN file;Code class BIN file and configuration class BIN file are checked for integrity, and the file and visual memory distribution information that pass the check are output, to obtain the burnable BIN file that satisfies preset requirement.The application can improve the reliability when generating multi-module BIN file.

Description

Technical Field

[0001] This invention relates to the field of embedded generation technology, and in particular to a method and apparatus for collaborative generation of BIN files for multiple DSP modules. Background Technology

[0002] An embedded digital signal processor (DSP) is a microprocessor designed specifically for real-time digital signal processing tasks (such as filtering, transformation, encoding and decoding). It converts the generic object file format (COFF) .out file generated by the linker into a programmable BIN file. In specific embedded systems, through hardware multipliers, parallel processing architectures, and efficient instruction sets, it can complete the digital acquisition, calculation, and control output of analog signals with limited power consumption and storage resources. It is the core processing unit for many embedded applications with extremely high real-time and reliability requirements.

[0003] In related technologies, the conversion results of traditional DSPs have problems such as poor readability and redundancy in size. They lack a verification mechanism and cannot verify the key data of the generated BIN file, which exacerbates the uncertainty risk of the system. At the same time, when generating BIN files with different functions, the process of splicing multiple independent tools is involved, which makes the conversion process cumbersome and the reliability of the results low.

[0004] Therefore, there is an urgent need for a collaborative generation method and apparatus for BIN files of multiple DSP modules to solve the above-mentioned technical problems. Summary of the Invention

[0005] This invention provides a method and apparatus for collaboratively generating BIN files for multiple modules of a DSP, which can effectively improve the efficiency and reliability of the results when generating BIN files for multiple modules of a DSP. The technical solution is as follows: On the one hand, a collaborative generation method for BIN files of multiple DSP modules is provided, the method comprising: Based on the module generation commands and corresponding files input by the user, the task is parsed and scheduled to obtain the corresponding task generation instructions; among them, the module types include code modules and configuration modules, and the input files include COFF files and configuration files; When the instruction is to generate a code class module, the memory execution layout of the DSP linker script is parsed, and the effective segment filtering and address relocation of the file header and segment header of the COFF file are performed according to the parsed address mapping table to obtain the original code class BIN file and visualized memory distribution information. When the instruction is to generate a configuration class module, the text-formatted configuration file is parsed and converted sequentially according to the predefined parameter offset and verification algorithm to obtain a configuration class BIN file with built-in integrity verification. The integrity of the code class BIN file and the configuration class BIN file is verified, and the verified file and the visualized memory distribution information are output to obtain a programmable BIN file that meets the preset requirements.

[0006] On the other hand, a collaborative generation device for BIN files of DSP multi-modules is provided, the device comprising: The parsing module is used to parse and schedule tasks based on user-input module generation commands and corresponding files to obtain corresponding task generation instructions. The module types include code modules and configuration modules, and the input files include COFF files and configuration files. The first generation module is used to parse the memory execution layout of the DSP linker script when the instruction is a code generation module, and to perform effective segment filtering and address relocation on the file header and segment header of the COFF file according to the parsed address mapping table, so as to obtain the original code class BIN file and visualized memory distribution information. The second generation module is used to parse the parameters and convert the format of the text-formatted configuration file according to the predefined parameter offset and verification algorithm when the instruction is to generate the configuration class module, so as to obtain the configuration class BIN file with built-in integrity verification. The verification module is used to perform integrity verification on the code class BIN file and the configuration class BIN file, and output the verified file and visualized memory distribution information to obtain a programmable BIN file that meets the preset requirements.

[0007] On the other hand, a computer device is provided, the computer device including a memory and a processor, the memory for storing computer programs, and the processor for executing the computer programs stored in the memory to implement the steps of the above-described collaborative generation method for DSP multi-module BIN files.

[0008] On the other hand, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, it implements the steps of the above-described collaborative generation method for DSP multi-module BIN files.

[0009] On the other hand, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the above-described collaborative generation method for DSP multi-module BIN files.

[0010] The technical solution provided by this invention offers at least the following benefits: Through a "centralized control scheduling - dual-branch generation - unified verification" architecture, it systematically solves the core defects of traditional DSP BIN generation tools. Interactive central control scheduling enables one-click generation of multiple modules, replacing the manual splicing process of multiple tools and significantly improving development efficiency. By using CMD address mapping and COFF valid segment extraction, address misalignment problems are avoided at the source, and invalid segments such as .bss are eliminated, reducing the BIN file size by 30%-70%, significantly lowering storage hardware costs. The BIN file has a built-in verification mechanism to ensure the integrity of critical data. The data integrity verification system and address validity check reduce the data error detection rate to near zero. Combined with visualized memory distribution output and user-defined conversion strategies, it significantly lowers the debugging threshold. This solution has been successfully applied to multiple models, including the C7 Flyer, meeting the batch programming and on-orbit update requirements of high-reliability scenarios such as aerospace and automotive electronics. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart of a collaborative generation method for BIN files of multiple DSP modules provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the parsing and generating file provided in an embodiment of the present invention; Figure 3 This is an example diagram of CMD file memory allocation provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the visualized memory distribution information of load.bin provided in an embodiment of the present invention; Figure 5 This is a structural diagram of a collaborative generation device for DSP multi-module BIN files provided in an embodiment of the present invention. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0014] As mentioned earlier, the conversion results of traditional DSPs have problems such as poor readability and redundant size. They lack a verification mechanism and cannot verify the key data of the generated BIN file, which exacerbates the uncertainty risk of the system. At the same time, the conversion process is cumbersome and the results are unreliable because of the splicing process of calling multiple independent tools when generating BIN files with different functions.

[0015] Based on this, the concept of the present invention is to provide a collaborative generation method for BIN files of multiple DSP modules to improve versatility and programming reliability.

[0016] The specific implementation of the above concept is described below.

[0017] Please refer to Figure 1 This invention provides a method for collaborative generation of BIN files for multiple DSP modules, the method comprising: Step 100: Based on the module generation command and corresponding file input by the user, perform task parsing and scheduling to obtain the corresponding task generation instruction; wherein, the module type includes code module and configuration module, and the input file includes COFF file and configuration file; Step 102: When the instruction is to generate code class module, the memory operation layout of DSP linker script is parsed, and the effective segment filtering and address relocation of the file header and segment header of the COFF file are performed according to the parsed address mapping table to obtain the original code class BIN file and visualized memory distribution information. Step 104: When the instruction is to generate a configuration class module, the text-formatted configuration file is parsed and converted sequentially according to the predefined parameter offset and verification algorithm to obtain a configuration class BIN file with built-in integrity verification. Step 106: Perform integrity verification on the code class BIN file and the configuration class BIN file, and output the verified file and visualized memory distribution information to obtain a programmable BIN file that meets the preset requirements.

[0018] In this embodiment of the invention, a "centralized control scheduling - dual-branch generation - unified verification" architecture systematically solves the core defects of traditional DSP BIN generation tools. Interactive central control scheduling enables one-click generation of multiple modules, replacing the manual splicing process of multiple tools and significantly improving development efficiency. Through CMD address mapping and COFF valid segment extraction, address misalignment problems are avoided at the source, and invalid segments such as .bss are eliminated, reducing the BIN file size by 30%-70%, significantly lowering storage hardware costs. The BIN file has a built-in verification mechanism to ensure the integrity of critical data. The data integrity verification system and address validity verification reduce the data error detection rate to near zero. Combined with visualized memory distribution output and user-defined conversion strategies, the debugging threshold is significantly lowered. This solution has been successfully applied to multiple models, including the C7 supercomputer, meeting the batch programming and on-orbit update requirements of high-reliability scenarios such as aerospace and automotive electronics.

[0019] The following description Figure 1 The execution method of each step is shown.

[0020] First, for step 100, the task is parsed and scheduled based on the module generation command and corresponding file input by the user to obtain the corresponding task generation instruction.

[0021] In this embodiment of the invention, when the file generation tool is started, it will display the prompt message: input load or app, press enter:, waiting for the user to input a command.

[0022] like Figure 2 As shown, the module reads the user input and generates a command string (case-sensitive, e.g., LOAD and load are equivalent), and configures the corresponding conversion parameters according to the command: Type `load`: This will open the `load.out` file and generate `load.bin`. Type 'app': This will open the 'app.out' file and generate 'app.bin'. Type `burn`: Open the `burn.out` file and generate `burn.bin`; Type cfg: Open the cfg.txt file and generate cfg.bin.

[0023] It is worth noting that the module types include code modules and configuration modules. The code modules include the load, app, and burn modules, while the configuration modules include the cfg module. The input files include COFF files and configuration files. The COFF files include the load.out, app.out, and burn.out files, while the configuration files include the cfg.txt file.

[0024] Next, open the corresponding input file (load.out / app.out / burn.out / cfg.txt) according to the command, and create the corresponding output BIN file handle; if the file fails to open, output an error message and terminate.

[0025] Then, for step 102, when the instruction is to generate a code class module, the memory execution layout of the DSP linker script is parsed, and the effective segment filtering and address relocation of the file header and segment header of the COFF file are performed according to the parsed address mapping table to obtain the original code class BIN file and visualized memory distribution information.

[0026] The DSP linker script (CMD file) defines the DSP memory layout through MEMORY and SECTIONS allocation requirements: the MEMORY section divides the memory operating regions (such as VECT, BOOT, TEXT, RAM, etc.) and specifies the starting address (origin) and length (length). The SECTIONS section maps segments to specific storage regions (e.g., .vecs>VECT), implementing address binding. In this method, segments such as .vecs, .boot, .text, .switch, .cinit, .const, .data, and .bss are defined according to functional requirements.

[0027] like Figure 3 As shown, the address definitions in CMD are dynamically matched with the COFF segment addresses to ensure that the BIN file strictly corresponds to the hardware address space and avoid address misalignment.

[0028] In this embodiment of the invention, the memory execution layout of the DSP linker script is parsed, including: Based on the MEMORY allocation requirements in the DSP linker script, the predefined content of the memory operating region is parsed line by line, parameters are extracted and structured to obtain a memory operating region table that records the starting address, length and purpose of each region.

[0029] Specifically, it reads the user-specified DSP linker script (.cmd file) and parses the MEMORY allocation requirement block line by line: Extract all predefined memory runtime region names (such as VECT interrupt vector region, BOOT boot sector, TEXT code sector, RAM runtime memory sector); The two core parameters for each region are: origin (starting address of the running region) and length (total length of the region), for example, VECT: origin=0x00000000h, length=0x00000200h; Construct a memory operating region table to record the address range and purpose of all regions, which will serve as the basis for subsequent memory boundary verification.

[0030] Furthermore, based on the SECTIONS allocation requirements in the DSP linker script, the binding rules between the COFF segment and the memory execution region are parsed and mapped one by one to obtain a segment-region binding table that clearly defines the range of legal memory execution addresses for each COFF segment.

[0031] Specifically, the SECTIONS allocation requirement block in the CMD file is parsed to extract the binding rules between all COFF segments and memory execution regions (in the format of segment name > memory execution region name), for example: .vecs>VECT: The interrupt vector segment must be mapped to the VECT runtime area; .boot>BOOT: The boot code segment must be mapped to the BOOT runtime area; .text>TEXT: The main program code segment must be mapped to the TEXT execution area; Construct a segment-region binding table to define the range of memory addresses that are allowed to be stored in each COFF segment.

[0032] Furthermore, based on the memory operating region table and the segment-region binding table, the correspondence between the COFF segment virtual address (i.e., the memory operating address) and the BIN file physical storage region is calculated using base address offset and global mapping relationship construction, resulting in a COFF segment virtual address-BIN file physical offset mapping table used to convert virtual addresses into BIN file physical offsets.

[0033] Specifically, based on the memory runtime region table and the segment-region binding table, the DSP memory base address offset (dspOffset) corresponding to each .out file (load.out / app.out / burn.out) is calculated: that is, the starting address of the total memory runtime region; Generate a global virtual address-BIN file physical storage offset mapping table. The core mapping relationship is: BIN file physical storage offset = COFF segment virtual address - dspOffset of the corresponding .out file (load.out / app.out / burn.out); This mapping table enables automatic conversion from "COFF segment runtime virtual address" to "BIN file burning physical offset", ensuring that the DSP can load data from the correct burning location to the specified runtime address after startup.

[0034] Finally, based on the segment-region binding table and the virtual start address and segment size information of the COFF segments to be processed, boundary out-of-bounds checks and legality verifications are performed on the memory usage range of all COFF segments to obtain memory out-of-bounds exception prompts or valid address mapping benchmarks.

[0035] Specifically, it iterates through all pending COFF segments and checks whether the virtual start address plus the segment size of each segment exceeds the address range of its bound memory operating region according to the segment-region binding table. If a segment out of bounds is detected (e.g., the size of the .text segment exceeds the reserved length of the TEXT region), it immediately outputs the error message "section out of memory" and terminates the process to prevent data from overwriting other regions during burning and causing the program to crash.

[0036] In this embodiment of the invention, the file header and segment header of the COFF file are filtered for valid segments and their addresses are relocated based on the parsed address mapping table to obtain the original code class BIN file and visualized memory distribution information, including: Based on the predefined COFF file header magic number and optional header magic number, the input COFF format target file is checked for the integrity of the file header and optional header, and a valid file that passes the check is obtained.

[0037] Specifically, the file header is first validated. The file header FILEHDR of the .out file is read, the magic number field f_magic is extracted, and it is compared with the predefined FILEHDR_MAGIC (the COFF format identifier corresponding to the target DSP model). If they do not match, the error "invalid coff file" is output and the process exits, ensuring that the input file is a valid DSP target file.

[0038] Next, the optional header is validated by checking the f_opthdr field in the file header. If the value of this field is non-zero (indicating the presence of the optional header OPTHDR), the optional header is read and its magic number OPTHDR_MAGIC is verified. This further confirms the integrity of the file format and excludes corrupted or tampered input files.

[0039] Furthermore, based on the number of segments in the file header and the offset of the segment header table, the segment header table of the legitimate file is traversed and the core metadata is extracted to obtain a complete set of segment information, including all segment names s_name, file offsets s_rawptr, virtual addresses s_vaddr, and segment sizes s_size, as well as standard segment debugging logs.

[0040] Specifically, the segment count field f_nscns is extracted from the file header, and the starting position of the segment header table is located by the file offset field s_rawptr in the segment header (SECHDR) that points to the original data and the file operation command fseek; Loop through each segment header (SECHDR) and extract the core metadata for each segment: s_name: Section name (e.g., .text, .data, .bss); s_rawptr: The physical offset of the segment data in the .out file, used to read the raw data; s_vaddr: The expected execution address of the segment in DSP memory (allocated by the linker based on the CMD file); s_size: The total number of bytes in the segment data; Print metadata information (segment name, virtual address, size) for all standard segments that begin with a dot, and generate debug logs to help developers verify the linking results.

[0041] Furthermore, based on the module generation command and predefined module segment filtering rules, the entire segment information set is filtered for valid segments and invalid segments are removed to obtain a list of valid segments that only contain segments directly related to program execution.

[0042] When the flag is 'a' (processing application segment), 'l' (processing boot segment), 'b' (processing programming segment), or 'c' (processing configuration file), the predefined key segments are filtered respectively, and only segments directly related to program execution (such as code, data, interrupt vectors) are extracted, while unnecessary segments (.bss segments, etc.) are removed, reducing the BIN size and adapting to the storage layout requirements of different DSP models.

[0043] For example, for the load program, app program, and burn program, vecs (interrupt vector table), .boot (boot kernel code), .text (boot auxiliary code), .data (initialize global variables), .switch (boot jump table), .cinit (C runtime initialization table), and .const (constant data) are the valid segments extracted; .bss (uninitialized data segment), .cio (standard I / O segment), and .system (system segment) are the invalid segments removed.

[0044] Next, for each segment in the list of valid segments, the relocation calculation from the virtual address to the physical offset of the BIN file is performed and the data is written according to the mapping relationship recorded in the virtual address-BIN file physical offset mapping table.

[0045] The process includes the following steps: Based on the memory runtime region table and the segment-region binding table, calculate the DSP memory base address offset (dspOffset) corresponding to each COFF file (load.out / app.out / burn.out): that is, the starting address of the total memory runtime region; The physical offset write address of the current valid segment in the BIN file is determined based on the difference between the virtual address of the current valid segment and the offset of the DSP memory base address. Position the file pointer to the beginning of the current valid segment data in the COFF file, and read the corresponding bytes of raw binary data according to the size of the valid segment; Position the file pointer to the beginning of the physical write address of the BIN file, and write the read segment's raw binary data into the BIN file buffer.

[0046] Meanwhile, discontinuous virtual address regions between different segments can be directly concatenated with valid continuous BIN data without filling in invalid data through this segmented mapping method, resulting in the original body of the code-type BIN file that has not undergone final integrity verification.

[0047] For example, allocate a memory buffer for the output BIN file, and for each selected valid segment, perform the following operations: Query the dspOffset corresponding to this segment from the mapping table provided in the preceding steps; Calculate the physical write address of this segment in the BIN file: binAddr = secHdr.s_vaddr - dspOffset; Use fseek to locate the starting position (secHdr.s_rawptr) of this data segment in the .out file, and read the raw data of secHdr.s_size bytes; The fseek command locates the binAddr position in the BIN file, and the read segment data is written to the buffer. If multiple valid segments are mapped to different virtual memory areas (with non-contiguous addresses), there is no need to fill in invalid data. The mapped valid data is directly concatenated to generate a continuous binary BIN file, ensuring that the programming tool can write to Flash in one go.

[0048] For example, if the address of the .vecs segment is defined as 0x00000000 in CMD, then dspOffset = 0x00000000. If the .text segment's s_vaddr = 0x00000400, then the offset in the BIN file is 0x00000400 - dspOffset. Finally, the data is located using fseek and written to the corresponding position in the BIN file using fwrite. This method significantly reduces the size of the BIN file, improves storage efficiency, and lowers storage costs through data parsing, extraction, and compression techniques.

[0049] Finally, based on the full segment information, the effective segment address translation results, and the predefined exception handling rules, unknown segmentation errors during the segment resolution process are captured and indicated, and the mapping relationship between the COFF virtual address segment and the PROM physical address is visualized, resulting in a visualized memory distribution report containing segment resolution exception information and address mapping verification logs.

[0050] Specifically, for handling unknown segment errors: if a segment name not in the predefined list is encountered when traversing the segment header table, the error message secname 'xxx' err is output, and the virtual address and size of the segment are recorded to help developers troubleshoot linker script configuration problems; For address mapping verification output: print the DSP running address (s_vaddr) and BIN file offset address (binAddr) of each valid segment, so that developers can manually check the correctness of the address translation; For generating a visual memory distribution: it generates a mapping diagram between COFF virtual address segments and PROM physical addresses, intuitively showing the location, size, and occupancy ratio of each segment in the BIN file, and quickly identifying address conflicts and space waste issues.

[0051] Taking the .text segment as an example, if the load address of the .text segment is defined as 0x00000300 in the CMD script, the COFF format parsing reveals that the segment size is 0x3e40 bytes, and the address offset of this segment in the generated BIN file is 0x300. Figure 4 The image shows the visualized memory distribution information of load.bin.

[0052] For step 104, when the instruction is to generate a configuration class module, the text-formatted configuration file is parsed and its format is converted sequentially according to the predefined parameter offset and verification algorithm to obtain a configuration class BIN file with built-in integrity verification.

[0053] In this embodiment of the invention, the configuration class BIN file is obtained through the following steps: The configuration file input by the user is validated for legality, and the memory space is initialized to obtain a binary data buffer for the reserved validation byte area.

[0054] Specifically, firstly, based on the incoming scheduling instructions, it attempts to open the user-specified text format configuration file cfg.txt in read-only mode; If the file fails to open (e.g., file does not exist, path is incorrect, permissions are insufficient), immediately output the error message "nosuch file!!" and terminate the process; If the file is opened successfully, a memory buffer with a size of the predefined constant CFG_BIN_SIZE bytes (which is an integer multiple of 4) is created, and all bytes in the buffer are initialized to 0x00. Four consecutive bytes of space (offset from CFG_BIN_SIZE-4 to CFG_BIN_SIZE-1) are reserved at the end of the buffer specifically for storing the built-in checksum value for subsequent calculations. The initial value of this area is also 0x00.

[0055] Furthermore, based on predefined configuration file syntax rules, the text-format configuration file is processed line by line to extract parameters and convert the format, resulting in valid configuration parameter data in binary format.

[0056] Specifically, the process reads the contents of cfg.txt line by line, parses the configuration parameters according to predefined syntax rules, and converts the hexadecimal values ​​in text format into binary data, including the following steps: Read the contents of the cfg.txt file line by line, automatically skipping blank lines and comment lines starting with # (compatible with common configuration file syntax). For a valid configuration line, find the position of the first colon: in the line, identify the content before the colon as the parameter name, and the content after the colon as the hexadecimal parameter value; Remove whitespace characters (spaces, tabs, newlines) before and after the parameter value, and verify that it is a valid hexadecimal string (only 0-9, af, and AF are allowed). If an illegal character, a missing colon separator, or an empty parameter value is detected, the error message "invalid parameter at line X" (where X is the line number) will be output and the process will terminate. Convert the verified hexadecimal parameter value into binary data of the corresponding byte length. The byte length of the parameter value is fixed at 4 bytes.

[0057] Examples of predefined configuration parameters are shown in Table 1 below: Table 1 Furthermore, the converted binary configuration parameter data and the initialized buffer are written according to the parameter offset and the buffer boundary is checked to obtain a buffer filled with all valid configuration parameters.

[0058] Specifically, the converted binary parameter data is written to the corresponding position in the buffer according to a predefined offset to ensure that the bootloader can read the configuration information at a fixed address. This includes the following steps: Based on the predefined parameter-offset mapping table, query the starting offset of the buffer corresponding to the currently parsed parameter; The converted binary parameter data is written to the buffer starting from this offset, and the writing length is strictly consistent with the byte length of the parameter. If the parameter data exceeds the buffer boundary during writing (i.e., offset + byte length > CFG_BIN_SIZE-4), the error message "parameter out of buffer" will be output and the process will be terminated. Repeat the above process until all valid configuration lines in cfg.txt have been parsed and written.

[0059] It is worth noting that the offset and byte length of all parameters must be completely consistent with the parsing code in the DSP bootloader; otherwise, the bootloader will read incorrect configuration information, causing the system to fail to start.

[0060] Based on the preset verification algorithm and the target DSP byte order, word accumulation and calculation are performed on all configuration parameters in the buffer except for the reserved verification byte area to generate verification values, resulting in complete binary buffer data with built-in integrity verification.

[0061] Specifically, read all data in the buffer except for the last 4 bytes of the reserved area (i.e., offset 0x0000 to CFG_BIN_SIZE-5). Traverse the above data in 4-byte units (word units), and sum all the word data to obtain the data sum dataSum; The verification value is calculated based on the predefined verification algorithm: Verification value = Fixed constant (WORD_SUM) - dataSum; The calculated 32-bit check value is written into the 4-byte reserved area at the end of the buffer according to the byte order of the target DSP. Closed-loop verification: After writing is complete, the word sum of the entire buffer (including the last 4 bytes of checksum) will be strictly equal to the fixed constant WORD_SUM. When the bootloader runs, it only needs to calculate the word sum of the entire cfg.bin file to quickly verify the integrity of the configuration file.

[0062] Finally, the complete binary buffer data is written to the created output file to obtain the configuration class BIN file.

[0063] Specifically, the output file cfg.bin is created in binary write mode; all bytes of the entire buffer (a total of CFG_BIN_SIZE bytes) are written to the cfg.bin file at once; if the file writing fails (e.g., insufficient disk space, write permission denied), the error message "write cfg.bin failed" is output and the process is terminated; after writing is complete, the handles to the cfg.txt input file and the cfg.bin output file are closed, and the memory buffer is released; the debug message "cfg.bingeneratedsuccessfully" is output, indicating that the configuration file generation is complete.

[0064] For step 106, the integrity of the code class BIN file and the configuration class BIN file is verified, and the verified file and the visualized memory distribution information are output to obtain a programmable BIN file that meets the preset requirements.

[0065] In this embodiment of the invention, the programmable BIN file is obtained through the following steps: Obtain the total number of bytes in the BIN file to be verified and perform file size verification based on the obtained result to obtain the file size constraint verification result.

[0066] Specifically, the corresponding original BIN file (load.bin / app.bin / burn.bin / cfg.bin) is opened in binary read-only mode; if the file fails to open, the error message "open bin file failed" is output and the process is terminated.

[0067] Move the file pointer from the beginning of the file to the end of the file, and use the ftell function to get the total number of bytes in the file, binSize, to verify if the file size meets expectations. For cfg.bin: Check if binSize is strictly equal to the predefined constant CFG_BIN_SIZE. If they do not match, output "cfg bin size error" and terminate. For code-type BIN files: check if binSize is greater than 0 and does not exceed the total length of the corresponding memory runtime storage area; if it exceeds, output "bin size out of memory" and terminate. Reset the file pointer to the beginning of the file to prepare for subsequent verification operations.

[0068] Furthermore, the first and last target byte segments of the BIN file to be verified are compared with the pre-stored expected values ​​to obtain the first integrity verification result.

[0069] Specifically, the file pointer is positioned at offset 0x0000, 3 consecutive bytes of data are read, converted to hexadecimal format, and printed out; then the file pointer is positioned at offset binSize-3, 3 consecutive bytes of data are read, converted to hexadecimal format, and printed out. The first and last bytes read are compared with the expected values ​​stored by the developer (the expected values ​​are uniquely determined by the DSP compilation and linking results); if the first and last bytes do not match the expected values, the error message "head / tail byte mismatch" is output immediately and the process is terminated without performing subsequent time-consuming accumulation and verification.

[0070] Furthermore, after reading all the data of the BIN file by traversing the preset byte window, the first data conversion and accumulation calculation are performed, and the deep integrity verification is performed based on the calculation result to obtain the second integrity verification result.

[0071] For example, by traversing the entire file in units of 4 bytes (words), the sum of all word data is calculated, and single-bit or multi-bit flip errors that occur during transmission or writing can be accurately detected.

[0072] Reset the file pointer to the beginning of the file and initialize the 32-bit unsigned integer variable wordSum = 0x00000000; The file content is read in 4-byte units, and each 4-byte data read is converted into a 32-bit unsigned integer according to the byte order of the target DSP. The converted integers are accumulated into the wordSum variable, and the overflowing high bits are automatically discarded during the accumulation process (i.e., modulo 2^32 operation). The loop executes until the end of the file, printing the final wordSum hexadecimal value (e.g., wordsum=0xeb90146f in the document example).

[0073] Since the aforementioned steps have written a built-in checksum value at the end of each bin, the word sum of each bin is strictly equal to the expected value fixed constant WORD_SUM stored by the developer. Therefore, for each bin, it is necessary to verify whether wordSum is equal to WORD_SUM. If they are not equal, a checksum error is output and the process is terminated.

[0074] Next, all data in the BIN file is read byte by byte, and after the second data conversion and accumulation calculation are completed, fine-grained integrity verification is performed to obtain the third integrity verification result.

[0075] Specifically, the entire file is traversed byte by byte, and the sum of all bytes is calculated as a supplement to the word sum check, further improving error detection capabilities and identifying special error scenarios that cannot be covered by the word sum.

[0076] Reset the file pointer to the beginning of the file again, and initialize the 32-bit unsigned integer variable byteSum = 0x00000000; The file content is read byte by byte, each byte is converted into an 8-bit unsigned integer and then accumulated into the byteSum variable, and the overflowing high bits are automatically discarded. The loop continues until the end of the file, printing the final hexadecimal value of byteSum (e.g., bytesum=0xf660a in the document example). The calculated byteSum is compared with the expected value stored by the developer. If they do not match, the byte summismatch is output and the process is terminated.

[0077] It is worth noting that the error detection capability of byte summation is slightly lower than that of word summation, but the calculation logic is simpler. It can be used as a lightweight verification method during the runtime of DSP bootloader, forming a double guarantee with word summation.

[0078] Finally, a complete verification report is generated based on the verification results of all verifications, and the BIN file that has passed all verifications is output as a programmable BIN file and visualized memory distribution information.

[0079] Specifically, if all verification steps (file size, first and last bytes, word sum, and byte sum) pass, the following operations are performed: print the success message "coff to bin success"; generate a complete verification report, including: file name, total file size, first 3 bytes, last 3 bytes, word sum, and byte sum; retain the verified BIN file as the final output, keeping the filename unchanged (load.bin / app.bin / burn.bin / cfg.bin); close the BIN file handle and release all occupied system resources; and output a visual summary of the verification results to help developers quickly confirm the file status.

[0080] In addition, all errors that occur during the verification process need to be categorized and processed, and precise error location information needs to be output to help developers quickly troubleshoot problems. For example: File operation errors: such as file not found, insufficient permissions, insufficient disk space, etc., output the corresponding system error code and prompt message; Formatting errors: such as file size not meeting expectations, mismatched first and last bytes, etc., prompting developers to check the integrity of the input file; Data errors: such as mismatch in word summation or byte summation, prompting developers to check the COFF parsing, data writing, or configuration file parsing process; All error messages include the stage at which the error occurred and the specific reason, avoiding vague and generic prompts.

[0081] In addition to the steps described above, this embodiment of the invention also defines a collaborative working mechanism for the four generated BIN files in the DSP system, which is the final implementation of the technical solution: First, the burning locations include: load.bin (boot software module): burned to the DSP's on-chip PROM; cfg.bin (configuration information module) and app.bin (application software module): burned to the fixed storage area of ​​the DSP's off-chip FLASH; burn.bin (programming software module): Programs cfg.bin and app.bin to the fixed storage area of ​​the DSP's external FLASH; Next, the following startup process will be executed: After power-on, the DSP's on-chip ROM automatically loads and executes load.bin to complete the DSP hardware initialization; The boot software reads cfg.bin from FLASH, verifies its integrity and parses it to obtain key configurations such as loading source and loading size; The boot software reads app.bin from FLASH according to the configuration parameters, verifies its integrity, and then moves it to the target runtime memory area. The bootloader jumps to the entry function of the application software, transferring control to the application software to implement the DSP's main business logic.

[0082] Please refer to Figure 5 This invention provides a collaborative generation device for BIN files of multiple DSP modules, the device comprising: The parsing module 500 is used to parse and schedule tasks based on the module generation commands and corresponding files input by the user, and to obtain the corresponding task generation instructions; among them, the module types include code modules and configuration modules, and the input files include COFF files and configuration files; The first generation module 502 is used to parse the memory execution layout of the DSP linker script when the instruction is a code generation module, and to perform effective segment filtering and address relocation on the file header and segment header of the COFF file according to the parsed address mapping table, so as to obtain the original code class BIN file and visualized memory distribution information. The second generation module 504 is used to parse the parameters and convert the format of the text-formatted configuration file sequentially according to the predefined parameter offset and verification algorithm when the instruction is to generate a configuration class module, so as to obtain a configuration class BIN file with built-in integrity verification. The verification module 506 is used to perform integrity verification on the code class BIN file and the configuration class BIN file, and output the verified file and the visualized memory distribution information to obtain a programmable BIN file that meets the preset requirements.

[0083] In this embodiment of the invention, the parsing of the memory execution layout of the DSP linker script includes: Based on the MEMORY allocation requirements in the DSP linker script, the predefined contents of the memory running storage area are parsed line by line, parameters are extracted and structured to obtain a memory running area table that records the starting address, length and purpose of each area; Based on the SECTIONS allocation requirements in the DSP linker script, the binding rules between the COFF segment and the memory runtime storage area are parsed and mapped one by one to obtain a segment-region binding table that clearly defines the range of legal memory runtime addresses for each COFF segment. Based on the memory running region table and the segment-region binding table, the correspondence between the COFF segment virtual address (i.e., memory running address) and the BIN file physical storage region is calculated by base address offset and global mapping relationship is constructed to obtain the COFF segment virtual address-BIN file physical offset mapping table used to convert the virtual address into the BIN file physical offset. Based on the segment-region binding table and the virtual start address and segment size information of the COFF segments to be processed, boundary out-of-bounds checks and legality verifications are performed on the memory usage range of all COFF segments to obtain memory out-of-bounds exception prompts or valid address mapping benchmarks.

[0084] In this embodiment of the invention, the step of performing effective segment filtering and address relocation on the file header and segment header of the COFF file according to the parsed address mapping table to obtain the original code class BIN file and visualized memory distribution information includes: Based on the predefined COFF file header magic number and optional header magic number, the input COFF format target file is checked for the integrity of the file header and optional header, and a valid file that passes the check is obtained. Based on the number of segments in the file header and the offset of the segment header table, the segment header table of the legal file is traversed and the core metadata is extracted to obtain a full set of segment information containing all segment names, file offsets, virtual addresses, segment sizes and standard segment debugging logs. Based on the module generation command and the predefined module segment filtering rules, the full set of segment information is filtered for valid segments and invalid segments are removed to obtain a list of valid segments that only contain segments directly related to program execution. For each segment in the list of valid segments, according to the mapping relationship recorded in the virtual address-BIN file physical offset mapping table, the relocation calculation from virtual address to BIN file physical offset is performed and the data is written. The data of different segments after writing are directly concatenated to obtain the original body of the code-class BIN file that has not undergone final integrity verification. Based on the full segment information, the effective segment address translation results, and the predefined exception handling rules, unknown segmentation errors during the segment resolution process are captured and indicated. The mapping relationship between the COFF virtual address segment and the PROM physical address is visualized, resulting in a visualized memory distribution report that includes segment resolution exception information and address mapping verification logs.

[0085] In this embodiment of the invention, for each segment in the list of valid segments, according to the mapping relationship recorded in the virtual address-BIN file physical offset mapping table, relocation calculation and data writing from virtual address to BIN file physical offset are performed, including: Calculate the DSP memory base address offset (dspOffset) for each .out file (load.out / app.out / burn.out) from the memory runtime region table and the segment-region binding table: that is, the starting address of the total memory runtime region; The physical offset write address of the current valid segment in the BIN file is determined based on the difference between the virtual address of the current valid segment and the offset of the DSP memory base address. Position the file pointer to the beginning of the current valid segment data in the COFF file, and read the corresponding bytes of raw binary data according to the size of the valid segment; Position the file pointer to the beginning of the physical write address of the BIN file, and write the read segment's raw binary data into the BIN file buffer.

[0086] In this embodiment of the invention, the step of sequentially parsing and converting the text-formatted configuration file according to predefined parameter offsets and verification algorithms to obtain a configuration class BIN file with built-in integrity verification includes: The configuration file input by the user is validated for legality, and the memory space is initialized to obtain a binary data buffer for the reserved validation byte area; Based on the predefined configuration file syntax rules, the text-format configuration file is processed line by line to extract parameters and convert the format, resulting in valid configuration parameter data in binary format. The converted binary configuration parameter data and the initialized buffer are written and the buffer boundary is checked according to the parameter offset to obtain a buffer filled with all valid configuration parameters. Based on the preset verification algorithm and the target DSP byte order, word accumulation and calculation are performed on all configuration parameters in the buffer except for the reserved verification byte area to generate verification values, resulting in complete binary buffer data with built-in integrity verification. Write the complete binary buffer data to the created output file to obtain the configuration class BIN file.

[0087] In this embodiment of the invention, the step of performing integrity verification on the code class BIN file and the configuration class BIN file, and outputting the verified file and visual memory distribution information to obtain a programmable BIN file that meets preset requirements includes: Obtain the total number of bytes in the BIN file to be verified and perform file size verification based on the obtained result to obtain the file size constraint verification result. The first and last target byte segments of the BIN file to be verified are compared with the pre-stored expected values ​​to obtain the first integrity verification result. After reading all the data of the BIN file by traversing the preset byte window, the first data conversion and accumulation calculation are performed, and the deep integrity verification is performed based on the calculation result to obtain the second integrity verification result. The entire data of the BIN file is read byte by byte, and after the second data conversion and accumulation calculation are completed in the reading results, fine-grained integrity verification is performed to obtain the third integrity verification result. A complete verification report is generated based on the verification results of all verifications, and the BIN file that passes all verifications is output as a programmable BIN file and visualized memory distribution information.

[0088] It should be noted that the collaborative generation device for DSP multi-module BIN files provided in the above embodiments is only an example of the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the collaborative generation device for DSP multi-module BIN files provided in the above embodiments and the collaborative generation method embodiments for DSP multi-module BIN files belong to the same concept, and the specific implementation process is detailed in the method embodiments, which will not be repeated here.

[0089] Embodiments of this application also provide a computer device, which includes a processor and a memory. The memory stores at least one instruction, at least one program, code set, or instruction set. The at least one instruction, at least one program, code set, or instruction set is loaded and executed by the processor to implement the collaborative generation method of DSP multi-module BIN file provided in the above-described method embodiments.

[0090] Embodiments of this application also provide a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by a processor to implement the collaborative generation method of DSP multi-module BIN files provided in the above-described method embodiments.

[0091] Embodiments of this application also provide a computer program product, which includes a computer program. A processor of a computer device reads the computer program from a computer-readable storage medium and executes the computer program, causing the computer device to perform the collaborative generation method of DSP multi-module BIN files as described in any of the above embodiments.

[0092] For ease of description, the above systems or devices are described separately as various modules or units based on their functions. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware components.

[0093] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0094] Finally, it should be noted that in this document, relational terms such as first, second, third, and fourth are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0095] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for collaborative generation of BIN files for multiple DSP modules, characterized in that, The method includes: Based on the module generation commands and corresponding files input by the user, the task is parsed and scheduled to obtain the corresponding task generation instructions; among them, the module types include code modules and configuration modules, and the input files include COFF files and configuration files; When the instruction is to generate a code class module, the memory execution layout of the DSP linker script is parsed, and the effective segment filtering and address relocation of the file header and segment header of the COFF file are performed according to the parsed address mapping table to obtain the original code class BIN file and visualized memory distribution information. When the instruction is to generate a configuration class module, the text-formatted configuration file is parsed and converted sequentially according to the predefined parameter offset and verification algorithm to obtain a configuration class BIN file with built-in integrity verification. The integrity of the code class BIN file and the configuration class BIN file is verified, and the verified file and the visualized memory distribution information are output to obtain a programmable BIN file that meets the preset requirements.

2. The method as described in claim 1, characterized in that, The parsing of the memory execution layout of the DSP linker script includes: Based on the MEMORY allocation requirements in the DSP linker script, the predefined content of the memory operating region is parsed line by line, parameters are extracted and structured to obtain a memory operating region table that records the starting address, length and purpose of each region; Based on the SECTIONS allocation requirements in the DSP linker script, the binding rules between the COFF segment and the memory execution region are parsed and mapped one by one to obtain a segment-region binding table that clearly defines the range of legal memory execution addresses for each COFF segment. Based on the memory operating region table and the segment-region binding table, the base address offset is calculated and a global mapping relationship is constructed for the correspondence between the COFF segment memory operating virtual address and the BIN file physical storage region, resulting in the COFF segment virtual address-BIN file physical offset mapping table used to convert the virtual address into the BIN file physical offset. Based on the segment-region binding table and the virtual start address and segment size information of the COFF segments to be processed, boundary out-of-bounds checks and legality verifications are performed on the memory usage range of all COFF segments to obtain memory out-of-bounds exception prompts or valid address mapping benchmarks.

3. The method as described in claim 2, characterized in that, The process involves filtering valid segments and relocating addresses in the file header and segment header of the COFF file based on the parsed address mapping table, resulting in the original code class BIN file and visualized memory distribution information, including: Based on the predefined COFF file header magic number and optional header magic number, the input COFF format target file is checked for the integrity of the file header and optional header, and a valid file that passes the check is obtained. Based on the number of segments in the file header and the offset of the segment header table, the segment header table of the legal file is traversed and the core metadata is extracted to obtain a full set of segment information containing all segment names, file offsets, virtual addresses, segment sizes and standard segment debugging logs. Based on the module generation command and the predefined module segment filtering rules, the full set of segment information is filtered for valid segments and invalid segments are removed to obtain a list of valid segments that only contain segments directly related to program execution. For each segment in the list of valid segments, according to the mapping relationship recorded in the virtual address-BIN file physical offset mapping table, the relocation calculation from virtual address to BIN file physical offset is performed and the data is written. The data of different segments after writing are directly concatenated to obtain the original body of the code-class BIN file that has not undergone final integrity verification. Based on the full segment information, the effective segment address translation results, and the predefined exception handling rules, unknown segmentation errors during the segment resolution process are captured and indicated. The mapping relationship between the COFF virtual address segment and the PROM physical address is visualized, resulting in a visualized memory distribution report that includes segment resolution exception information and address mapping verification logs.

4. The method as described in claim 3, characterized in that, For each segment in the list of valid segments, according to the mapping relationship recorded in the virtual address-BIN file physical offset mapping table, perform relocation calculation and data writing from the virtual address to the BIN file physical offset, including: Calculate the DSP memory base address offset corresponding to each COFF file based on the memory runtime region table and the segment-region binding table; The physical write address of the current valid segment in the BIN file is determined based on the difference between the virtual address of the current valid segment and the offset of the DSP memory base address. Position the file pointer to the beginning of the current valid segment data in the COFF file, and read the corresponding bytes of raw binary data according to the size of the valid segment; Position the file pointer to the beginning of the physical write address of the BIN file, and write the read segment's raw binary data into the BIN file buffer.

5. The method as described in claim 1, characterized in that, The text-formatted configuration file is parsed and format converted sequentially based on predefined parameter offsets and verification algorithms to obtain a configuration class BIN file with built-in integrity verification, including: The configuration file input by the user is validated for legality, and the memory space is initialized to obtain a binary data buffer for the reserved validation byte area; Based on the predefined configuration file syntax rules, the text-format configuration file is processed line by line to extract parameters and convert the format, resulting in valid configuration parameter data in binary format. The converted binary configuration parameter data and the initialized buffer are written and the buffer boundary is checked according to the parameter offset to obtain a buffer filled with all valid configuration parameters. Based on the preset verification algorithm and the target DSP byte order, word accumulation and calculation are performed on all configuration parameters in the buffer except for the reserved verification byte area to generate verification values, resulting in complete binary buffer data with built-in integrity verification. Write the complete binary buffer data to the created output file to obtain the configuration class BIN file.

6. The method as described in claim 1, characterized in that, The process of performing integrity verification on the code class BIN file and the configuration class BIN file, and outputting the verified file and visual memory distribution information to obtain a programmable BIN file that meets preset requirements includes: Obtain the total number of bytes in the BIN file to be verified and perform file size verification based on the obtained result to obtain the file size constraint verification result. The first and last target byte segments of the BIN file to be verified are compared with the pre-stored expected values ​​to obtain the first integrity verification result. After reading all the data of the BIN file by traversing the preset byte window, the first data conversion and accumulation calculation are performed, and the deep integrity verification is performed based on the calculation result to obtain the second integrity verification result. The entire data of the BIN file is read byte by byte, and after the second data conversion and accumulation calculation are completed in the reading results, fine-grained integrity verification is performed to obtain the third integrity verification result. A complete verification report is generated based on the verification results of all verifications, and the BIN file that passes all verifications is output as a programmable BIN file and visualized memory distribution information.

7. A collaborative generation device for BIN files of multiple DSP modules, characterized in that, The device includes: The parsing module is used to parse and schedule tasks based on user-input module generation commands and corresponding files to obtain corresponding task generation instructions. The module types include code modules and configuration modules, and the input files include COFF files and configuration files. The first generation module is used to parse the memory execution layout of the DSP linker script when the instruction is a code generation module, and to perform effective segment filtering and address relocation on the file header and segment header of the COFF file according to the parsed address mapping table, so as to obtain the original code class BIN file and visualized memory distribution information. The second generation module is used to parse the parameters and convert the format of the text-formatted configuration file according to the predefined parameter offset and verification algorithm when the instruction is to generate the configuration class module, so as to obtain the configuration class BIN file with built-in integrity verification. The verification module is used to perform integrity verification on the code class BIN file and the configuration class BIN file, and output the verified file and visualized memory distribution information to obtain a programmable BIN file that meets the preset requirements.

8. A computer device, characterized in that, The computer device includes a memory and a processor. The memory is used to store computer programs, and the processor is used to execute the computer programs stored in the memory to implement the steps of the method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the steps of the method described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the steps of the method according to any one of claims 1-6.

Images