Embedded chip simulation and debugging method and system

Abstract

The invention relates to an embedded chip simulation and debugging method and system. The method comprises the following steps: expanding an instruction decoding module, a register description module and a breakpoint management module which support a C28x instruction set in a GDB debugger, and generating a special debugging front-end program; the method comprises the following steps: expanding a C28x JTAG protocol adaptation module in an OpenOCD debugging agent, and generating a debugging agent program; a C28x instruction set execution simulation unit is realized in the NEMU simulator, and a GDB Server communication module is embedded in the NEMU simulator; seamless switching between a simulation debugging mode and a hardware debugging mode is realized based on a unified configuration file through a software and hardware debugging environment rapid switching control module. The problems that a traditional debugging mode depends on a special hardware simulator, the cost is high and the simulation environment is inaccurate are solved, and through an integrated software and hardware collaborative debugging scheme, the debugging cost is greatly reduced, and the development efficiency and the comprehensiveness of system verification are improved.

Description

Technical Field

[0001] This invention relates to the field of electronic engineering technology, and in particular to an embedded chip simulation and debugging method and system. Background Technology

[0002] With the widespread application of embedded chips in industrial automation, power electronics, and real-time control, the demand for debugging and simulation verification of embedded chips is increasing. Traditional debugging methods require dedicated simulators, debugging software, and hardware platforms, resulting in high debugging costs and making it difficult to meet the needs of rapid development and low-cost applications.

[0003] Furthermore, existing simulation environments are mostly simple instruction-level simulations, lacking detailed simulations of pipelines, interrupts, and peripheral behavior, and thus cannot effectively support comprehensive system-level verification. Therefore, developing an efficient and low-cost C28x chip simulation and debugging method and system that fully supports rapid switching between hardware and software environments is of significant practical importance. Summary of the Invention

[0004] The purpose of this invention is to provide an embedded chip simulation and debugging method and system. By adding support for the C28x architecture to the three components GDB, OpenOCD and NEMU respectively, and realizing a seamless switching mechanism between software and hardware debugging environments, debugging costs are reduced and development efficiency is improved.

[0005] To achieve the above objectives, the present invention provides an embedded chip simulation and debugging method, comprising the following steps:

[0006] Step S1: Extend the instruction decoding module, register description module, and breakpoint management module in the GDB debugger to support the C28x instruction set, and generate a GDB debugging front-end program for the C28x architecture;

[0007] Step S2: Extend the OpenOCD debug agent to support the debug adapter module of C28x chip, including the C28xJTAG protocol adapter unit, and generate an OpenOCD debug agent program that supports C28x chip.

[0008] Step S3: Implement the execution simulation unit of the C28x instruction set in the NEMU simulator framework, and embed the GDBServer communication module to perform debugging instruction parsing and status feedback with the GDB debugging front-end program through the GDB remote serial protocol;

[0009] Step S4: Quickly switch control modules between software and hardware debugging environments. When the system starts, it selects either simulation debugging mode or hardware debugging mode based on a unified configuration file, and achieves seamless switching under a unified debugging interface.

[0010] Preferably, the extended modules in the GDB debugger specifically include:

[0011] Step S1-1: Target architecture description unit. Add a new target description file target-c28x.c to the GDB source code to define the register structure of the C28x architecture, including 32 general-purpose registers, 8 auxiliary registers, status flag registers ST0 / ST1 and stack pointer SP;

[0012] Step S1-2: Instruction decoding and execution unit, which implements the instruction decoding routine decode_c28x_insn, which parses instruction opcodes, immediate values, and register operands based on the 16-bit instruction format of C28x, and supports arithmetic operations, logical operations, branch jumps, and memory access instruction sets;

[0013] Step S1-3: Breakpoint management control unit, add breakpoint management interface, rewrite target_stop function, and return C28X_SIGTRAP signal when breakpoint is triggered.

[0014] Preferably, the debugging adaptation module in the OpenOCD debugging agent includes:

[0015] Step S2-1: JTAG Configuration Unit, define JTAG TAP and register access instructions in the OpenOCD configuration file;

[0016] Step S2-2: Protocol extension unit, which extends support for the JTAG protocol of the C28x chip, defines the JTAG scan chain and TAP state machine, and implements the functions of CPU register access, program memory and data memory read and write.

[0017] Step S2-3: Flash driver unit, write the Flash controller driver program, including erase_sector(), write_word(), check_status() functions, to directly manipulate the Flash controller registers;

[0018] Step S2-4: Compile the build unit, modify the Makefile configuration, add C28x architecture compilation options, and generate a dedicated debugging agent.

[0019] Preferably, the execution simulation unit in the NEMU simulator includes:

[0020] Step S3-1: CPU state management subunit, add a CPU state structure to the NEMU framework, which includes the state of registers at each stage of the pipeline;

[0021] Step S3-2: Pipeline scheduling subunit, which implements the C28x pipeline scheduling function pipeline_schedule(), simulates the pipeline execution process of instructions, and integrates data conflict detection, control conflict handling and pipeline forwarding mechanisms;

[0022] Step S3-3: Peripheral simulation subunit, using address mapping and callback registration mechanism, maps PWM module, timer, ADC, SPI peripherals to specific memory address space, and simulates peripheral behavior through callback function;

[0023] Step S3-4: Interrupt the simulation subunit, check the interrupt request queue in each pipeline cycle and respond to interrupt requests in a timely manner;

[0024] Step S3-5: GDB Server communication subunit, embedded with GDB Server, to implement RSP protocol parsing, register read / write and memory read / write functions.

[0025] Preferably, the software and hardware debugging environment fast switching control module includes:

[0026] Step S4-1: Configure the management unit and set the GDB debugging target and OpenOCD interface parameters in the unified configuration file on the PC to support quick switching between simulation debugging and hardware debugging environments;

[0027] In simulation debugging mode, the connection to the NEMU's built-in GDB Server is made via a remote serial protocol; in hardware debugging mode, the connection to the OpenOCD debugging agent module is made via a remote serial protocol.

[0028] Step S4-2: Debug the monitoring unit. Through the GDB debugging interface, realize unified monitoring of the target program's simulation debugging and hardware debugging, and maintain the consistency of the debugging interface, breakpoint configuration and variable mapping.

[0029] Preferably, the GDB Server communication subunit includes:

[0030] The command parsing module parses remote serial protocol commands from the GDB debugging front end;

[0031] The simulator control module controls the simulator's execution flow based on the parsed commands, including pause, resume, single-step execution, and register and memory access operations;

[0032] The status feedback module feeds back the simulator's execution status to the GDB debugging front end via the GDB remote serial protocol.

[0033] Preferably, the instruction decoding routine decode_c28x_insn includes the following steps:

[0034] Based on the 16-bit instruction format of C28x, extract the instruction opcode field, register number field, and immediate number field;

[0035] The extracted immediate number segment is sign-extended to generate a 32-bit signed immediate number;

[0036] The instruction type is identified by the opcode field, distinguishing between arithmetic operations, logical operations, branch jumps, and memory access instructions.

[0037] The control signals required for instruction execution are generated and submitted to the simulator execution unit.

[0038] Preferably, the pipeline scheduling function pipeline_schedule() implements the following steps:

[0039] Maintain the state of the registers at each stage of the pipeline, including the instruction fetch register, decode register, execute register, memory access register, and write-back register;

[0040] Execute a data conflict detection algorithm to detect RAW, WAR, and WAW conflicts through register correlation analysis;

[0041] The execution control conflict handling mechanism performs target address prediction and pipeline cleanup operations for branch instructions;

[0042] A pipeline forwarding mechanism is adopted to directly forward the results of the previous pipeline to the subsequent instructions that need the results;

[0043] At the end of each pipeline cycle, the state of each level of registers is updated to advance the simulation execution progress.

[0044] This invention provides an embedded chip simulation and debugging system, comprising:

[0045] The PC is equipped with the GDB debugging front-end program and the OpenOCD debugging agent program.

[0046] The C28x target board contains an embedded processor based on the C28x architecture;

[0047] JTAG debugging interface, connecting the PC and C28x target board;

[0048] A C28x emulator based on NEMU, running on a PC;

[0049] The GDB debugging front-end program connects to the GDBServer module in the simulator via the GDB remote serial protocol, issues debugging commands and receives simulation status feedback.

[0050] The OpenOCD debugging agent is a compiler that extends support for the C28x architecture. It connects to and controls the C28x target board through the JTAG interface to perform hardware debugging and status feedback.

[0051] The PC and the target board communicate bidirectionally via the JTAG interface to complete the hardware and software co-debugging and verification of the C28x chip.

[0052] Preferably, the GDB debugging front-end and OpenOCD debugging agent on the PC share a unified configuration file. The configuration file adopts a structured data format and includes fields for debugging mode selection, interface parameters, target architecture identifier, and Flash security settings. It can quickly switch between simulation debugging and hardware debugging modes according to development needs, providing an integrated debugging process.

[0053] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0054] This invention integrates GDB, OpenOCD, and the NEMU simulator to form a complete debugging and simulation solution for the C28x architecture. This reduces reliance on dedicated hardware emulators, significantly lowers debugging costs, and improves development efficiency. Furthermore, this invention supports rapid switching between debugging environments, simultaneously meeting simulation and hardware debugging needs, and offers strong portability and wide applicability. Attached Figure Description

[0055] To make the content of this invention easier to understand, the invention will be further described in detail below with reference to specific embodiments and accompanying drawings.

[0056] Figure 1 This is a schematic diagram of the overall structure of the debugging system in an embodiment of the present invention.

[0057] Figure 2 This is a flowchart illustrating the communication process between GDB and the simulator in an embodiment of the present invention.

[0058] Figure 3 This is a schematic diagram illustrating the communication between OpenOCD and the target board in an embodiment of the present invention.

[0059] Figure 4 This is a schematic diagram illustrating the state transition when switching between software and hardware debugging environments in an embodiment of the present invention. Figure 5 This is a schematic diagram of the instruction-level operation mechanism of the C28x architecture simulator in an embodiment of the present invention. Detailed Implementation

[0060] Example 1

[0061] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that the drawings are all in simplified form and are only for illustrating the embodiments of the present invention.

[0062] like Figure 1 As shown, this embodiment of the invention provides an embedded chip simulation and debugging system, including a PC, a C28x target board, a JTAG interface, and a C28x simulator based on NEMU. The PC is equipped with a GDB debugging front-end and an OpenOCD debugging agent program. These two programs communicate with the GDB Server communication module embedded in the NEMU via the GDB remote serial protocol to achieve instruction parsing, debugging command issuance, and status feedback. OpenOCD connects to the target board via the JTAG interface for hardware debugging.

[0063] To verify the consistency between the simulated and hardware debugging environments, the system ran the same test cases in both environments, including metrics such as single-step debugging response time, breakpoint trigger latency, register read / write accuracy, and Flash write speed. Experimental results show that the average latency in simulation mode is 3.6 microseconds, and in hardware mode it is 3.4 microseconds, with an error of less than 5%. Breakpoint response times are 1.2 and 1.1 milliseconds respectively, and the register access error rate is less than 0.1%, verifying the timing accuracy and reliability of the simulated environment.

[0064] Example 2

[0065] This embodiment provides a method for simulating and debugging embedded chips, including:

[0066] In this embodiment, the instruction decoding module, register description module, and breakpoint management module are implemented in GDB for debugging the front-end program.

[0067] First, implement the target architecture description unit. Add a new target description file (target-c28x.c) to the GDB source code, which contains the register definition structure, including 32 general-purpose registers, 8 auxiliary registers, status flag registers ST0 / ST1, and stack pointer SP.

[0068] Secondly, an instruction decoding execution unit is implemented. This unit implements the instruction decoding routine decode_c28x_insn. The decoding method of this routine is as follows: based on the 16-bit instruction format of C28x, the opcode, registers and immediate number segment are extracted, and sign extension processing is performed to support the parsing of instructions such as arithmetic operations, logical operations, branch jumps, and memory access.

[0069] Finally, a breakpoint management control unit is implemented. By adding a breakpoint management interface and rewriting the target_stop function, it is made to return the C28X_SIGTRAP signal when a breakpoint is triggered.

[0070] This embodiment of the OpenOCD debugging agent program extends OpenOCD with a debugging adapter module that supports C28x chips.

[0071] The JTAG configuration unit is implemented by defining JTAG TAP and register access instructions in the OpenOCD configuration file.

[0072] The protocol extension unit extends support for the JTAG protocol of the C28x chip, defines the JTAG scan chain and TAP state machine, and implements CPU register access, program memory and data memory read and write functions.

[0073] The Flash driver unit has written a FLASH driver, which includes functions such as erase_sector(), write_word(), and check_status(), and directly manipulates the Flash controller registers.

[0074] The compilation build unit generates a debug agent that supports the C28x architecture by modifying the Makefile and adding compilation options.

[0075] In this embodiment of the NEMU simulator, the execution simulation unit is implemented in the NEMU simulator framework and the GDBServer communication module is embedded.

[0076] The CPU state management subunit adds a CPU state structure to the NEMU framework, which includes registers for each stage of the pipeline.

[0077] The pipeline scheduling subunit implements the C28x pipeline scheduling function `pipeline_schedule()`. This function implements a pipeline simulation method that includes: simulating the pipeline execution process of instructions, implementing data conflict detection, control conflict handling, and pipeline forwarding mechanisms to complete instruction execution.

[0078] The peripheral simulation subunit adopts an address mapping and callback registration mechanism to map peripherals such as PWM modules, timers, ADCs, and SPIs to specific memory address spaces, and simulates peripheral behavior through callback functions.

[0079] The interrupt simulation subunit checks the interrupt request queue in each pipeline cycle and responds promptly.

[0080] The GDB Server communication subunit is embedded within the GDB Server, implementing RSP protocol parsing, register read / write, and memory read / write. This subunit includes:

[0081] The command parsing module parses remote serial protocol commands from GDB;

[0082] The simulator control module controls the simulator's execution flow based on the parsed commands, including pausing, resuming, single-step execution, and register and memory access.

[0083] The status feedback module feeds back the simulator's execution status to the GDB debugging front end via the GDB remote serial protocol.

[0084] Specifically, the debugging command interaction uses the Remote Serial Protocol (RSP), which includes three stages: command sending, acknowledgment, and feedback. For example, the command "s" triggers single-step execution. After parsing, the GDB Server calls the pipeline_schedule function to execute one instruction cycle and returns a status packet "S05," with an average response latency of approximately 0.8 milliseconds. The system supports more than twenty commands, covering operations such as register read / write, breakpoint management, and memory access.

[0085] The software and hardware debugging environment can be quickly switched. In this embodiment, the mode switching is achieved through the software and hardware debugging environment quick switching control module.

[0086] The configuration management unit sets the target and OpenOCD interface used by GDB in a unified configuration file on the PC. The configuration file adopts a YAML structure and includes fields such as "mode", "interface", "target", "baudrate", and "flash_secure". The system reads the configuration at startup: when mode = "emu", it connects to the NEMU's built-in GDB Server module; when mode = "hw", it loads the OpenOCD debugging agent and identifies the target board's JTAG chain parameters.

[0087] The debugging and monitoring unit ensures that the target program can be uniformly monitored for simulation debugging and hardware debugging using the GDB debugging interface. The debugging interface, breakpoint configuration, and variable mapping remain consistent, allowing developers to seamlessly switch debugging environments and providing an integrated debugging workflow.

[0088] like Figure 2 As shown, the communication process between GDB and the simulator in this invention is as follows: The GDB debugging front end sends a debugging command to the GDB Server, the GDB Server module embedded in the simulator parses and executes the command, and sends back status information to GDB.

[0089] like Figure 3 As shown, the communication process between OpenOCD and the target board in this invention includes: connecting to the target board via a JTAG interface; the OpenOCD debugging agent program receiving and executing debugging commands from the PC to achieve register access and memory read / write; and the target board providing feedback on the debugging status via the JTAG interface.

[0090] like Figure 4As shown, the flowchart of the C28x instruction decoding mechanism of this invention is as follows: The C28x instruction parsing process includes instruction fetching, pre-decoding, decoding, control signal generation, execution, and conflict judgment. The processor reads the instruction from the program memory, determines whether it is 16-bit or 32-bit through pre-decoding, and then performs operand fetching and control signal generation accordingly. The decoding result is sent to the execution unit. The system checks for pipeline conflicts; if any exist, the conflict is handled; otherwise, the program counter is updated, and the next instruction is executed. This process ensures the correct identification and execution of different instruction formats.

[0091] like Figure 5 As shown, the state diagram of the instruction-level operation mechanism of the C28x architecture simulator in this invention is as follows: The simulator execution process can be divided into several key states, including fetch, decode, execute, memory access, write_back, interrupt_check, etc.

[0092] The system initially starts in the fetch state, reading the instruction at the address pointed to by the program counter (PC). It then enters the decode phase, parsing the instruction format, extracting fields such as the opcode, register number, and immediate value, and determining whether it is a jump instruction or an instruction that may cause a hazard. If a data hazard exists, the system jumps to the check_hazard state to determine the hazard and schedule the forwarding path. If necessary, a NOP instruction is inserted, and the system rolls back to the decode phase to pause pipeline progression. If it is a jump instruction, the system enters the handle_branch module to calculate the target address and predict the jump. If the prediction fails, the system jumps to the flush state to clear the IF and ID phase caches and re-enters the fetch state to execute the corrected instruction path.

[0093] After the instruction is decoded without errors, it enters the execute phase, performing arithmetic and logical operations or address calculations. Next, it enters the memory phase to perform data access operations, such as loading or writing to RAM. Upon completion, the instruction enters the write_back phase, writing the calculation result back to the register bank and updating the relevant status register flags. The final stage of the instruction's lifecycle is interrupt_check. During this phase, the system checks for any unmasked interrupt requests. If one exists, the current instruction stream is interrupted, the context is saved, and the system jumps to the address specified in the interrupt vector table to execute the interrupt service routine. If a HALT signal or a program termination instruction is received, the system enters the halt state, and the execution flow ends.

[0094] This state machine design takes into account both the pipeline characteristics of the C28x processor and the performance requirements of software simulation. It can not only accurately simulate the complex instruction behavior and control logic in actual hardware, but also provide an accurate state interface for the upper-level debugging system, which is helpful for fault backtracking and system verification.

[0095] In summary, the integrated debugging and simulation scheme proposed in this invention achieves a high degree of integration of debugging and simulation of C28x architecture chips, simplifies the development and debugging process, reduces development costs and difficulties, and has significant practical significance and broad application prospects for C28x chip development.

[0096] The above description is merely a preferred embodiment of the present invention. Those skilled in the art can make corresponding modifications and variations based on the above disclosure, all of which fall within the protection scope of the present invention. The above description is only a description of a preferred embodiment of the present invention and is not intended to limit the scope of the present invention in any way. Any changes or modifications made by those skilled in the art based on the above disclosure fall within the protection scope of the claims.

Claims

1. An embedded chip simulation and debugging method, characterized in that, Includes the following steps: Step S1: Extend the instruction decoding module, register description module, and breakpoint management module in the GDB debugger to support the C28x instruction set, and generate a GDB debugging front-end program for the C28x architecture; Step S2: Extend the OpenOCD debug agent to support the debug adapter module of C28x chip, including the C28x JTAG protocol adapter unit, and generate an OpenOCD debug agent program that supports C28x chip. Step S3: Implement the execution simulation unit of the C28x instruction set in the NEMU simulator framework, and embed the GDB Server communication module to perform debugging instruction parsing and status feedback with the GDB debugging front-end program through the GDB remote serial protocol; Step S4: Quickly switch control modules between software and hardware debugging environments. When the system starts, it selects either simulation debugging mode or hardware debugging mode based on a unified configuration file, and achieves seamless switching under a unified debugging interface.

2. The embedded chip simulation and debugging method as described in claim 1, characterized in that, The extended modules in the GDB debugger specifically include: Step S1-1: Target architecture description unit. Add a new target description file target-c28x.c to the GDB source code to define the register structure of the C28x architecture, including 32 general-purpose registers, 8 auxiliary registers, status flag registers ST0 / ST1 and stack pointer SP; Step S1-2: Instruction decoding and execution unit, which implements the instruction decoding routine decode_c28x_insn, which parses instruction opcodes, immediate values, and register operands based on the 16-bit instruction format of C28x, and supports arithmetic operations, logical operations, branch jumps, and memory access instruction sets; Step S1-3: Breakpoint management control unit, add breakpoint management interface, rewrite target_stop function, and return C28X_SIGTRAP signal when breakpoint is triggered.

3. The embedded chip simulation and debugging method as described in claim 1, characterized in that, The debugging adaptation module in the OpenOCD debugging agent includes: Step S2-1: JTAG Configuration Unit, define JTAG TAP and register access instructions in the OpenOCD configuration file; Step S2-2: Protocol extension unit, which extends support for the JTAG protocol of the C28x chip, defines the JTAG scan chain and TAP state machine, and implements the functions of CPU register access, program memory and data memory read and write. Step S2-3: Flash driver unit, write the Flash controller driver program, including erase_sector(), write_word(), check_status() functions, to directly manipulate the Flash controller registers; Step S2-4: Compile the build unit, modify the Makefile configuration, add C28x architecture compilation options, and generate a dedicated debugging agent.

4. The embedded chip simulation and debugging method as described in claim 1, characterized in that, The execution simulation unit in the NEMU simulator includes: Step S3-1: CPU state management subunit, add a CPU state structure to the NEMU framework, which includes the state of registers at each stage of the pipeline; Step S3-2: Pipeline scheduling subunit, which implements the C28x pipeline scheduling function pipeline_schedule(), simulates the pipeline execution process of instructions, and integrates data conflict detection, control conflict handling and pipeline forwarding mechanisms; Step S3-3: Peripheral simulation subunit, using address mapping and callback registration mechanism, maps PWM module, timer, ADC, SPI peripherals to specific memory address space, and simulates peripheral behavior through callback function; Step S3-4: Interrupt the simulation subunit, check the interrupt request queue in each pipeline cycle and respond to interrupt requests in a timely manner; Step S3-5: GDB Server communication subunit, embedded with GDB Server, to implement RSP protocol parsing, register read / write and memory read / write functions.

5. The embedded chip simulation and debugging method as described in claim 1, characterized in that, The rapid switching control module for the software and hardware debugging environment includes: Step S4-1: Configure the management unit and set the GDB debugging target and OpenOCD interface parameters in the unified configuration file on the PC to support quick switching between simulation debugging and hardware debugging environments; In simulation debugging mode, the connection to the NEMU's built-in GDB Server is made via a remote serial protocol; in hardware debugging mode, the connection to the OpenOCD debugging agent module is made via a remote serial protocol. Step S4-2: Debug the monitoring unit. Through the GDB debugging interface, realize unified monitoring of the target program's simulation debugging and hardware debugging, and maintain the consistency of the debugging interface, breakpoint configuration and variable mapping.

6. The embedded chip simulation and debugging method as described in claim 4, characterized in that, The GDB Server communication subunit includes: The command parsing module parses remote serial protocol commands from the GDB debugging front end; The simulator control module controls the simulator's execution flow based on the parsed commands, including pause, resume, single-step execution, and register and memory access operations; The status feedback module feeds back the simulator's execution status to the GDB debugging front end via the GDB remote serial protocol.

7. The embedded chip simulation and debugging method as described in claim 2, characterized in that, The instruction decoding routine decode_c28x_insn includes the following steps: Based on the 16-bit instruction format of C28x, extract the instruction opcode field, register number field, and immediate number field; The extracted immediate number field is sign-extended to generate a 32-bit signed immediate number; The instruction type is identified by the opcode field, distinguishing between arithmetic operations, logical operations, branch jumps, and memory access instructions. The control signals required for instruction execution are generated and submitted to the simulator execution unit.

8. The embedded chip simulation and debugging method as described in claim 4, characterized in that, The pipeline scheduling function `pipeline_schedule()` performs the following steps: Maintain the state of the registers at each stage of the pipeline, including the instruction fetch register, decode register, execute register, memory access register, and write-back register; Execute a data conflict detection algorithm to detect RAW, WAR, and WAW conflicts through register correlation analysis; The execution control conflict handling mechanism performs target address prediction and pipeline cleanup operations for branch instructions; A pipeline forwarding mechanism is adopted to directly forward the results of the previous pipeline to the subsequent instructions that need the results; At the end of each pipeline cycle, the state of each level of registers is updated to advance the simulation execution progress.

9. An embedded chip simulation and debugging system, serving to implement the steps of the method as described in any one of claims 1 to 8, characterized in that, include: The PC is equipped with the GDB debugging front-end program and the OpenOCD debugging agent program. The C28x target board contains an embedded processor based on the C28x architecture; JTAG debugging interface, connecting PC and C28x target board; A C28x emulator based on NEMU, running on a PC; The GDB debugging front-end program connects to the GDB Server module in the simulator via the GDB remote serial protocol, issues debugging commands and receives simulation status feedback. The OpenOCD debugging agent is a compiler that extends support for the C28x architecture. It connects to and controls the C28x target board through the JTAG interface to perform hardware debugging and status feedback. The PC and the target board communicate bidirectionally via the JTAG interface to complete the hardware and software co-debugging and verification of the C28x chip.

10. An embedded chip simulation and debugging system as described in claim 9, characterized in that, The GDB debugging front-end and OpenOCD debugging agent on the PC share a unified configuration file. The configuration file adopts a structured data format and includes fields for debugging mode selection, interface parameters, target architecture identifier, and Flash security settings. It can quickly switch between simulation debugging and hardware debugging modes according to development needs, providing an integrated debugging process.

Images