MCU burning test vector generation method based on protocol conversion

Abstract

The invention discloses an MCU burning test vector generation method based on protocol conversion, and relates to the field of integrated circuit testing. According to the method, the standard FLM file representing the Flash programming algorithm of the target chip and the Intel HEX file containing the user firmware are deeply analyzed, and the standard PAT test vector script meeting the requirements of the target ATE platform is automatically generated in combination with strict following of SWD protocol rules. According to the process, seamless conversion from a firmware file to an executable test vector is realized, and an internal mechanism covers cooperative processing stages of parameter configuration and file import, key information analysis and standardization, SWD protocol operation sequence generation, final PAT vector script synthesis output and the like; manual intervention and tedious format conversion links in a traditional scheme are effectively eliminated.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit testing, and more specifically to a method for generating MCU programming test vectors based on protocol conversion. Background Technology

[0002] In the field of integrated circuit mass production testing, MCU firmware programming and automatic test equipment (ATE) functional verification are generally separated, and the current technical approach has significant shortcomings. On the one hand, MCU firmware programming relies on dedicated debugging tools, such as programmers based on the JTAG protocol, to perform Flash write and erase operations, while ATE independently completes functional verification. The two are physically isolated at the device level, and the switching process requires manual intervention for interface plugging and unplugging and fixture replacement, leading to test process interruptions and significantly extending the test cycle. On the other hand, data processing also has problems. The underlying algorithm parsing of Flash Load Module (FLM) files is limited by specific programmer vendor tools and cannot be natively parsed by the ATE system. At the same time, the standardized processing of HEX (Intel HEX File Format) files lacks a unified mechanism, which is disconnected from the test vector generation process, further exacerbating the complexity of data processing.

[0003] It is worth noting that existing local optimization solutions focus on local improvements and fail to overcome the barriers to systemic integration: while cloud-based programming optimizes the transmission process, it does not solve the functional coupling problem between the ATE and the programming execution unit; while vector generation optimization simplifies the conversion of data from specific sources, it does not address the automated generation of the core mapping relationship from FLM / HEX to test vectors. Crucially, all publicly available technical solutions have failed to establish a complete and automated mapping relationship between FLM file parsing, HEX file data conversion, and the PAT test vectors required by the target ATE platform. This fundamental deficiency forces engineers to be deeply involved in the underlying data processing, which not only significantly reduces the efficiency of test vector generation but also significantly introduces operational errors and quality risks due to the increased manual steps.

[0004] In addition, each firmware update requires the chip to be returned to the factory for re-burning, which adds extra time and cost to mass production and severely restricts chip production efficiency.

[0005] Therefore, there is an urgent need for an end-to-end integrated solution that can deeply integrate burning functionality, natively parse key files (FLM / HEX), and automatically generate corresponding test vectors, in order to eliminate device switching, connect data flows, and improve testing efficiency and completeness. Summary of the Invention

[0006] To address the aforementioned shortcomings in existing technologies, this invention provides a method for generating MCU programming test vectors based on protocol conversion, which solves the problem that device switching and manual intervention significantly affect the efficiency and continuity of test vector generation in existing technologies.

[0007] To achieve the above-mentioned objectives, the technical solution adopted by this invention is as follows:

[0008] A method for generating MCU programming test vectors based on protocol conversion is provided, which includes the following steps:

[0009] Determine the relevant information of the target MCU based on the input chip model; configure the physical pin mapping relationship of the SWD debug interface signals on the target ATE test head; perform ELF format specification verification on the provided FLM file; perform type and data integrity verification on the provided HEX file;

[0010] For FLM files that pass the verification, the program structure parsing, symbol table location and key information extraction are performed in sequence. The load address of the FLM file code, the initial position of the stack pointer and the parsed Flash programming algorithm code are obtained and encapsulated into a data structure to form a C++ source file.

[0011] For HEX files that pass verification, they are converted into normalized 32-bit word sequences to form an address-data mapping table, realizing end-to-end conversion from the original HEX file to the burning parameters, and outputting executable text;

[0012] The memory layout is dynamically determined based on the relevant information of the target MCU; the information memory layout includes the memory space allocation for code, data buffer, static data area and stack area; the memory layout information is fixed in the output executable ELF file;

[0013] Based on the memory layout environment, C++ source files, and executable text, and according to the three-layer data interaction model of the SWD protocol, the underlying protocol operation sequence for accessing the debug port register and accessing the port register is generated. The ARM core control instructions and batch data block continuous read and write sequences are automatically synthesized. Through the protocol layering architecture, a PAT format file containing complete timing parameters and verification information that meets the target ATE requirements is output, thus completing the generation of MCU programming test vectors.

[0014] The beneficial effects of this invention are as follows: By constructing an end-to-end instruction generation mechanism driven by the SWD protocol state machine and combining it with a file deep parsing engine, this invention achieves fully automated conversion from source files to executable PAT test vectors for automated testing equipment. This solves the problems of device separation, data fragmentation, excessive manual intervention, and missing mapping relationships in the MCU firmware burning and ATE testing process. It achieves automated conversion from FLM / HEX to PAT vectors, eliminating device switching and data barriers, thus improving testing efficiency and enhancing compatibility. This invention can flexibly adapt to the configuration requirements of different manufacturers and models of MCUs, eliminating device switching and manual intervention in traditional processes, and significantly improving test vector generation efficiency, process continuity, and device compatibility. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating the method in this embodiment;

[0016] Figure 2 This is a flowchart illustrating the automated generation process of MCU firmware burning test vectors in this embodiment.

[0017] Figure 3 This is a schematic diagram of the PAT test vector generation process under the SWD protocol layered architecture in the embodiment.

[0018] Figure 4 This is a schematic diagram of the dynamic RAM model adaptation mechanism in the embodiment. Detailed Implementation

[0019] The specific embodiments of the present invention are described below to enable those skilled in the art to understand the present invention. However, it should be understood that the present invention is not limited to the scope of the specific embodiments. For those skilled in the art, various changes are obvious as long as they are within the spirit and scope of the present invention as defined and determined by the appended claims. All inventions utilizing the concept of the present invention are protected.

[0020] like Figure 1 As shown, the MCU programming test vector generation method based on protocol conversion includes the following steps:

[0021] S1. Determine the relevant information of the target MCU based on the input chip model; configure the physical pin mapping relationship of the SWD debug interface signals on the target ATE test head; perform ELF format specification verification on the provided FLM file; perform type and data integrity verification on the provided HEX file;

[0022] S2. For FLM files that pass the verification, the program structure parsing, symbol table location and key information extraction are executed in sequence. The load address of the FLM file code, the initial position of the stack pointer, and the parsed Flash programming algorithm code are obtained and encapsulated into a data structure to form a C++ source file.

[0023] S3. For HEX files that pass verification, convert them into standardized 32-bit word sequences to form an address-data mapping table, realizing end-to-end conversion from the original HEX file to the programming parameters, and outputting executable text. The purpose of this step is to extract the programming parameters from the verified HEX file into a text file for easy use later.

[0024] S4. Dynamically determine the memory layout based on the relevant information of the target MCU; the information memory layout includes the memory space allocation of code, data buffer, static data area and stack area; the memory layout information is fixed in the output executable ELF file;

[0025] S5. Based on the memory layout environment, C++ source files and executable text, and according to the three-layer data interaction model of the SWD protocol, it generates the underlying protocol operation sequence for accessing the debug port register and accessing the port register, automatically synthesizes the ARM core control instructions and batch data block continuous read and write sequence, and outputs a PAT format file containing complete timing parameters and verification information that meets the target ATE requirements through the protocol layering architecture, thus completing the generation of MCU programming test vectors.

[0026] In this embodiment, as Figure 2 As shown, MCU firmware burning testing requires system initialization and key parameter configuration. The necessary software processing modules for initialization include an integrated FLM parsing engine and protocol state machine, which automatically determine the target MCU's FLASH memory base address and required RAM size model based on the user-input chip model. The user configures the precise physical pin mapping of the SWD debug interface signals on the target ATE test head through the human-machine interface, while providing a standard format FLM algorithm file (FLM file) and an Intel HEX firmware file (HEX file). The system has a built-in file format verification mechanism to verify that the FLM file conforms to the ELF format specification and that the HEX file verifies its record type and data integrity, ensuring the legality of the input data and the reliability of subsequent processing.

[0027] Subsequently, the input data undergoes in-depth processing through core file parsing and data standardization. This method utilizes an integrated FLM parsing engine to sequentially perform program structure parsing, symbol table location, and key information extraction.

[0028] Specifically, the integrated FLM parsing engine in this embodiment, based on existing open-source ELF file parsing tools (especially the underlying parsing libraries of components in the GNU Binutils suite such as readelf, objdump, and ld), adds many new functions according to the special requirements of flash memory burning, forming a specially optimized three-layer parsing system. The improvements to this engine are mainly reflected in the following three aspects:

[0029] The first layer (basic structure parsing layer) primarily parses the basic structure of the ELF file. Existing standard tools can perfectly parse the ELF file header, program header table (segment header table), and section header table. It can clearly show which segments (such as .text, .data, .rodata) have what permissions (read, write, execute), as well as their virtual address (p_vaddr), file offset (p_offset), size (p_filesz, p_memsz), and other key information.

[0030] This engine examines the ELF file header to confirm the file type, then reads the program header table to identify the code segments that need to be loaded into memory. Based on this technical aspect, it focuses on code segments with execute and read / write permissions. To ensure correct code execution, it dynamically adjusts the code's load address by calculating the difference between the code segment's address in flash memory and its actual execution address. For example, in the STM32F103 chip, if the virtual address of a code segment in the ELF file is 0x08000000, while the chip's actual flash memory address is 0x20000000, the engine will automatically adjust the load address to 0x20000000 to ensure the code runs in the correct location.

[0031] The second layer (symbol table resolution layer) is responsible for resolving the symbol table. Existing standard tools primarily use symbol resolution for general development tasks such as debugging, disassembly, and linking, which require viewing as much symbol information as possible.

[0032] Building upon existing parsing techniques, this engine improves efficiency by simultaneously reading both the string table and the symbol table. The string table stores the names of functions and variables, while the symbol table records the memory addresses corresponding to these names. The engine first locates both the symbol table and the string table within the file, then reads their contents concurrently. During parsing, the engine cross-checks these two tables to ensure the correctness of the symbol information. For example, when the engine needs to find the address of the "Init" function, it first finds the entry for "Init" in the symbol table, then extracts the complete function name from the string table based on the information in that entry, and finally converts the function name into its actual memory address. To further enhance parsing speed, the engine also filters out unnecessary symbols, such as compiler-generated special symbols, retaining only critical flash memory operation functions like "Init," "EraseSector," and "ProgramPage."

[0033] The third layer (standard data structure generation layer) automatically adjusts the memory layout based on the chip's memory size when generating standard data structures. Existing standard tools do not generate standard data structures after parsing the ELF file for subsequent execution or programming. The linker determines the final memory layout (location of code, data, BSS, stack, and heap) based on the linker script and stores this information in a C++ source file. `readelf` / `objdump` can display this final layout.

[0034] This embodiment pre-configures several common memory sizes, such as 2KB, 4KB, and 8KB, and then dynamically allocates space for code, data, and the stack based on the actual memory size. An initial memory allocation scheme is first tried, and then the code execution process is simulated to check if there is sufficient space between the stack pointer and the code buffer. If the space is insufficient, the memory allocation is adjusted until a suitable scheme is found. For example, in the STM32F103 chip, if the memory size is 4KB, the code buffer might be placed at the beginning of the memory, and the stack pointer at the end, ensuring sufficient space between them to prevent errors during program execution.

[0035] Taking the STM32F103 chip as an example, when the engine parses an FLM file containing functions such as "Init," "EraseSector," and "ProgramPage," it first locates the code segment that needs to be loaded and loads the code into memory. Then, the engine parses the symbol table to find the address of the "Init" function. Finally, the engine adjusts the memory layout according to the available memory size to ensure the program runs correctly. The standardized data generated by the engine includes important information such as the code's load address and the initial position of the stack pointer, ensuring that the data is correctly aligned in memory for easy subsequent programming operations.

[0036] This embodiment uses a HEX conversion engine to process verified HEX files. The HEX conversion engine achieves efficient conversion of Intel HEX files to standardized 32-bit word sequences through a dynamic address space reconstruction algorithm. This engine uses a state machine mechanism to parse the HEX file structure. When an extended linear address record (type code 0x04) is detected, the high 16 bits of the base address are extracted and a 32-bit address frame is constructed. When processing a data record (type code 0x00), the offset address within the record is combined with the base address to form a complete linear address, and three key technology optimizations are implemented: By dynamically tracking the current address range, padding bytes (default 0xFF) are automatically inserted to fill the 4-byte gap when an address gap is detected, ensuring data continuity; byte order adaptive conversion is implemented based on the target chip architecture, for example, converting the byte sequence 3F C0 00 00 in the ARM Cortex-M little-endian environment to the 32-bit word 0x0000C03F; and 4-byte boundary padding is implemented at the end of the data block, for example, automatically padding 3 bytes of 0xFF to form a 20-byte aligned block for valid data of length 17 bytes, ensuring that the data is aligned by word boundaries.

[0037] Taking the firmware conversion of the XL6601 chip as an example, when parsing the extended address record `:020000040800F2` to lock the base address 0x08000000, and processing the data record `:102000003F404142434445464748494A4B4C4D4E4F81`, the starting address 0x08002000 is synthesized and 16 bytes of original data are loaded. When the next record address jump to 0x080 is detected, At 02014, 3 bytes of 0xFF are automatically inserted to form 4-byte alignment, and finally converted to normalized output according to little-endian (such as 0x4241403F, 0x46454443, 0x4A494847...). Based on the above process, in the actual test of the XL6601 chip, 23KB of scattered HEX data was successfully converted into 5750 aligned 32-bit words, forming an accurate address-data mapping table, realizing end-to-end conversion from the original file to the programming parameters.

[0038] The above mechanism enables the FLM parsing engine and the HEX conversion engine to work together to achieve the processing of "general format → burning special data" through segment filtering based on permission dimension, toolchain-independent symbol resolution, and architecture-adaptive data conversion.

[0039] like Figure 3 As shown, the protocol layered architecture establishes a hierarchical structure of physical layer, link layer, and application layer, generating precise operation sequences for the debug port (DP) and access port (AP) registers, and ultimately outputting a PAT format file containing complete timing parameters and verification information. The following section provides a detailed explanation of this protocol layered architecture from a technical implementation perspective:

[0040] At the physical layer, the state machine generates a SWDIO waveform sequence that strictly conforms to the timing constraints of the SWD protocol, namely "updating data on the falling edge and maintaining stability on the rising edge," based on predefined clock cycle parameters and level transition rules. Its accuracy stems from the quantitative modeling of the protocol timing parameters. For example, when generating the DP register access start bit, the state machine sets SWDIO to logic high level (1) on the preset Nth falling edge of SWCLK and maintains this state from the rising edge to the N+1th falling edge. Subsequent control fields (APnDP, RnW, A[2:3]) and parity bits (pre-calculated by performing XOR operations on key fields) are all output sequentially according to the same falling edge update rule to ensure that the signal switching point is strictly consistent with the protocol specification.

[0041] At the link layer data encapsulation level, this embodiment uses structured coding rules to statically convert operation instructions into a predefined test vector format. Taking the reading SW-DP IDCODE operation as an example: First, a standardized request header sequence is generated and solidified: start bit (1) + APnDP=0 (DP) + RnW=1 (read) + address bits A[2:3]=00 + parity bit (P) + stop bit (0) + park bit (1); then, the Trn waiting period specified by the protocol (such as the fixed level sequence corresponding to 2 SWCLK cycles), the preset ACK response state (such as OKAY=HLL), and the level sequence of the 32-bit RDATA field are preset—this sequence converts the preset target value (such as IDCODE=0x2BA01477) into the corresponding H / L level combination through bit mapping technology, and adds a parity bit. This encapsulation mechanism forms a reusable test vector module, which is suitable for initialization processes (such as JTAG to SWD, AHB-AP ID verification) and core register access.

[0042] At the application layer operation sequence generation level, the state machine adopts a preset differentiated access strategy based on the target register type: for direct access to debug port (DP) registers (such as IDCODE, SELECT), a single request packet and corresponding data segment (write operation) or simulated data segment (read operation) are generated; for indirect access to access port (AP) registers (such as CSW, TAR, DRW), the three-level access mechanism is strictly followed to generate the SWD protocol opcode sequence—taking the configuration of the AP's CSW register as an example, the following are generated in sequence: 1) DP SELECT write operation (set the APBANKSEL field, such as WDATA=0x000000F0 to select Bank 15); 2) AP TAR write operation (set the target register address, such as WDATA=0x00000000 pointing to CSW); 3) AP DRW write operation (write the control word, such as WDATA=0x23000012 to configure the data width and address auto-increment).

[0043] The three-layer model described above works collaboratively to generate a complete test vector file. Taking the ARM core suspension operation as an example: at the physical layer, all SWDIO timings are generated according to the falling edge update and rising edge hold rule; at the link layer, an AP write request packet (address 0xE000EDF0, data 0xA05F0003) containing the forced debug enable bit (C_DEBUGEN=1) is encapsulated; at the application layer, since the target register (DHCSR) belongs to the AP category, a three-level access sequence [DP SELECT(0x08) → AP TAR(0xE000EDF0) → AP DRW(0xA05F0003)] is automatically generated and stored in the PAT file. The final output PAT file serves as a statically pre-computed programming instruction set carrier, accurately containing the timing control signal states under all SWCLK cycles, and can directly drive the automated test equipment (ATE) to perform chip debugging and firmware programming.

[0044] Specifically, this embodiment utilizes the address auto-increment feature of the debug interface to generate an efficient sequence of continuous read and write operations for data blocks. The SWD protocol supports continuous read and write mode, which can be enabled by configuring the AddrInc[1:0] field of the CSW register (usually set to 0b10 to indicate 32-bit auto-increment), and combined with the TAR-DRW access pair to achieve efficient continuous transmission. Based on the physical pin mapping relationship of the SWD debug interface signals on the target ATE test head, the target ATE can be directly driven to perform chip debugging and firmware burning.

[0045] To simulate the actual programming process, this embodiment accurately generates and controls the ARM kernel state (suspend and resume). This precise implementation relies on PAT's support for C++ syntax and ensures the timing compliance of the SWD protocol through a layered architecture. Ultimately, the precision of "kernel suspension confirmation" is reduced from the software logic level to the clock granularity of the protocol physical layer: if the S_HALT flag (bit 17) of the Debug Control and Status Register (DHCSR) is read back as L, it indicates that the kernel is not suspended, and the loop will repeatedly initiate read requests according to the timing intervals predefined by the physical layer (such as 2 SWCLK cycles); if the S_HALT bit is H, it indicates that the kernel has entered the suspended state, the loop terminates and triggers the subsequent process: loading the FLM algorithm binary data into the target chip's SRAM at the specified starting address, setting the PC pointer to point to the algorithm function entry address, and finally executing the complete operation sequence of the erase or program function.

[0046] In this embodiment, to address the differences in RAM resource configurations among chips from different MCU manufacturers, this embodiment can also be extended to support a dynamic RAM model adaptation mechanism. For example... Figure 4 As shown, during the key information parsing and data standardization phase, the system can dynamically load or generate a matching RAM size configuration template based on the user-selected chip model or by directly parsing relevant information in the FLM file, and automatically adjust parameters such as stack space allocation and buffer location in the runtime data structure. For example, for low-end MCUs with limited on-chip SRAM resources, the system can optimize the algorithm loading address and compress the temporary data area; while for high-end MCUs with large-capacity RAM, a larger data buffer can be configured to improve batch programming efficiency. This dynamic adaptation mechanism significantly enhances the compatibility of the solution with different chip architectures and the optimization of resource utilization, expanding the applicability and performance boundaries of this automated toolchain in complex and ever-changing MCU mass production testing environments.

[0047] In summary, this invention, through in-depth analysis of the standard FLM file characterizing the Flash programming algorithm of the target chip and the Intel HEX file containing the user firmware, combined with strict adherence to SWD protocol rules, automatically generates standardized PAT test vector scripts that meet the requirements of the target ATE platform. This process achieves seamless conversion from firmware files to executable test vectors. Its internal mechanism encompasses collaborative processing stages including parameter configuration and file import, key information parsing and standardization, SWD protocol operation sequence generation, and final PAT vector script synthesis and output, effectively eliminating manual intervention and cumbersome format conversion steps in traditional solutions.

[0048] This invention dynamically plans the memory space allocation for algorithm code, data buffers, static data areas, and stack areas for target chips with different RAM resources, ensuring reliable loading and efficient execution of Flash programming algorithms in a limited RAM environment. Specifically, based on the user-configured target chip RAM size, this invention calculates and determines the starting address of the stack pointer, the base address and size of the program buffer, and the base address of the static data area. The program buffer temporarily stores the firmware data to be programmed, and its size is adaptively adjusted according to the total RAM capacity. The static data area is allocated immediately below the stack area and is used to store global variables required for algorithm execution. Simultaneously, this method loads the parsed and extracted Flash algorithm binary code into the RAM starting address region and, based on the dynamically calculated memory layout address, generates a standardized runtime data structure containing the entry addresses of key functions, the location of the program buffer, the initial value of the stack pointer, and the base address of the static data. This data structure provides a complete runtime environment for subsequent Flash erase / write operations via the SWD protocol, effectively solving the algorithm compatibility problem for chips with different RAM capacities and optimizing memory resource utilization efficiency.

[0049] This invention encompasses the generation of instruction sequences driven by the SWD protocol state machine and the design of standardized PAT output, applying a layered processing design from deep parsing of FLM / HEX files to precise mapping of ATE executable instructions. This standardized, fully automated processing chain allows firmware burning functionality to be directly integrated into the ATE testing process. Users only need to execute the generated PAT test vector script once on the target ATE to complete the entire process from Flash erasure and writing, firmware programming to functional verification, greatly improving the continuity of the testing process, equipment resource utilization, and mass production testing efficiency.

Claims

1. A method for generating MCU programming test vectors based on protocol conversion, characterized in that, Includes the following steps: Determine the relevant information of the target MCU based on the input chip model; configure the physical pin mapping relationship of the SWD debug interface signals on the target ATE test head; perform ELF format specification verification on the provided FLM file; perform type and data integrity verification on the provided HEX file; For FLM files that pass the verification, the program structure parsing, symbol table location and key information extraction are performed in sequence. The load address of the FLM file code, the initial position of the stack pointer and the parsed Flash programming algorithm code are obtained and encapsulated into a data structure to form a C++ source file. For HEX files that pass verification, they are converted into normalized 32-bit word sequences to form an address-data mapping table, realizing end-to-end conversion from the original HEX file to the burning parameters, and outputting executable text; The memory layout is dynamically determined based on the relevant information of the target MCU; The information memory layout includes the memory space allocation for code, data buffer, static data area and stack area; The memory layout information is stored in the output executable ELF file; Based on the memory layout environment, C++ source files, and executable text, and according to the three-layer data interaction model of the SWD protocol, the underlying protocol operation sequence for accessing the debug port register and accessing the port register is generated. The ARM core control instructions and batch data block continuous read and write sequences are automatically synthesized. Through the protocol layering architecture, a PAT format file containing complete timing parameters and verification information that meets the target ATE requirements is output, thus completing the generation of MCU programming test vectors.

2. The method according to claim 1, characterized in that, Information about the target MCU includes its RAM size; specific methods for dynamically determining the memory layout based on this information include: Based on the RAM size of the target MCU, calculate and determine the starting address of the stack pointer, the base address and size of the program buffer, and the base address of the static data area. The program buffer is used to temporarily store the firmware data to be burned, and its size is adaptively adjusted according to the total RAM capacity of the target MCU. The static data area is allocated immediately below the stack area and is used to store global variables required for algorithm execution.

3. The method according to claim 1, characterized in that, There are pre-configured memory layout schemes. When it is necessary to dynamically determine the memory layout, a pre-configured scheme is retrieved based on the RAM size of the target MCU. The execution process of the code is simulated, and it is checked whether there is enough space between the stack pointer and the code buffer. If so, the pre-configured scheme is selected; otherwise, the memory allocation is adjusted until there is enough space between the stack pointer and the code buffer.

4. The method according to claim 2, characterized in that, Program structure parsing, symbol table location, and key information extraction are performed by the integrated FLM parsing engine, which includes: The basic structure parsing layer is used to parse the ELF file header, segment header table, and section header table, displaying the segment permissions, virtual address, file offset, and size; it examines the ELF file header to confirm the file type, reads the segment header table, obtains the initial position of the stack pointer, finds the code segment that needs to be loaded into memory and obtains the code segment with execution and read / write permissions, and dynamically adjusts the code loading address based on the difference between the address of the code segment with execution and read / write permissions in flash memory and the actual execution address to ensure that the code runs in the correct location; The symbol table resolution layer is used to resolve symbols using existing standard tools; it reads the string table and symbol table, and performs cross-checking of the string table and symbol table using flash operation functions to ensure the correctness of symbol information; The standard data structure generation layer is used to encapsulate the load address of the FLM file code, the initial position of the stack pointer, and the parsed Flash programming algorithm code into data structures to form a C++ source file.

5. The method according to claim 1, characterized in that, For HEX files that pass verification, specific methods for converting them into normalized 32-bit word sequences include: A state machine mechanism is used to parse the HEX file structure. When an extended linear address record is detected, the high 16 bits of the base address are extracted and a 32-bit address frame is constructed. The data records are processed by combining the offset address within the record with the base address to form a complete linear address, and then a triple optimization is performed: First optimization: By dynamically tracking the current address range, padding bytes are automatically inserted to fill the 4-byte gap when an address gap is detected, ensuring data continuity; The second optimization: Implementing adaptive byte order conversion based on the target MCU architecture; The third optimization: Implement 4-byte boundary padding at the end of the data block to ensure that the data is aligned by word boundaries.

6. The method according to claim 1, characterized in that, The protocol layered architecture includes: The physical layer is used to generate SWDIO waveform sequences that strictly conform to the timing constraints of the SWD protocol, namely "update data on the falling edge and remain stable on the rising edge," based on predefined clock cycle parameters and level transition rules, ensuring that the signal switching points are strictly consistent with the SWD protocol specifications. The link layer is used to statically convert operation instructions into a predefined test vector format using structured coding rules. It presets the Trn waiting period, preset ACK response status, and level sequence of the 32-bit RDATA field specified by the SWD protocol. It converts the preset target value in the level sequence of the 32-bit RDATA field into the corresponding H / L level combination through bit mapping technology and adds parity bits to form a reusable test vector module. The application layer is used to adopt a preset differentiated access strategy based on the target register type; parse and process the operation response status; automatically synthesize ARM core control instructions and batch data block continuous read and write sequences; and output a PAT format file containing complete timing parameters and verification information that meets the target ATE requirements.

7. The method according to claim 6, characterized in that, Pre-defined differentiated access strategies include: For direct access to debug port registers, generate a single request packet and the corresponding data segment or simulated data segment; For indirect access to port registers, the SWD protocol opcode sequence is generated strictly following the three-level access mechanism.

8. The method according to claim 6, characterized in that, The PAT format file is a statically pre-calculated programming instruction set carrier, containing the timing control signal states under all SWCLK cycles. Based on the physical pin mapping relationship of the SWD debug interface signals on the target ATE test head, it can directly drive the target ATE to perform chip debugging and firmware programming.

9. The method according to claim 1 or 6, characterized in that, The specific methods for generating ARM core control instructions include: By employing a layered architecture to ensure the timing compliance of the SWD protocol, the precision of "kernel suspension confirmation" is reduced from the software logic level to the clock granularity of the protocol physical layer. If the S_HALT flag in the debug control and status register is read back as L, it means that the kernel is not suspended and the loop will repeatedly initiate read requests according to the time intervals predefined by the physical layer. If the S_HALT bit is H, it means that the kernel has entered a suspended state, the loop terminates, and the subsequent process is triggered.

10. The method according to claim 1 or 6, characterized in that, The batch data block continuous read / write sequence is generated through the address auto-increment feature of the debug interface.

Images