CN1312588C - Realizing method of cross regulator based on EJTAG components of targeting machine - Google Patents

Abstract

The present invention provides a scheme for using software to effectively control and use EJTAG components on an object machine. According to the scheme, the design and the realization of a cross debugger based on EJTAG are thereafter completed. The scheme is characterized in that all the processing procedures of the commands of the debugger operate on a host machine, only 4 to 5 signal wires are needed between the host machine and the object machine, and no extra hardware equipment is needed. The debugger with high performance price ratio realizes the debugging functions of an assemble level and a source code level which operates on the host machine, and has excellent adaptability and transferability.

Description

Implementation method of cross-debugger based on EJTAG components on target machine

technical field

The method for implementing a cross-debugger based on EJTAG components on a target machine belongs to the field of computer system debugging tools.

Background technique

When developing and producing new electronic and computer products, we often face the following problems: (1) The device layout of the circuit is becoming increasingly complex; (2) The miniaturization of components, complex packaging, and dense pins; and (3) circuit board miniaturization, use of surface soldering technology, etc. This brings a lot of trouble to the line test, fault inspection and elimination of the product. It is difficult or even impossible to use traditional line detection equipment. One way to solve this problem is to use Boundary Scan Technology (BST (Boundary Scan Technology). This technology is developed by the Joint Test Action Group (JTAG, Joint Test Action Group) of the IEEE Technical Committee (industry standard IEEE1149.1), and can be used to test the circuit board: (1) whether the logic of each device itself is correct; (2) each The connection between the devices; and (3) whether the combined devices have completed the intended functions, etc. Extended JTAG EJTAG (Enhanced JTAG) specification is an extension based on the JTAG specification. The operating object of EJTAG is the MIPS microprocessor of MIPS Company or the system-on-a-chip (SOC) chip component that contains the MIPS core. EJTAG provides the application interface for application program and core code software debugging. It has some of the following features:

1) Set a hardware breakpoint (Hardware Breakpoint);

2) Single Step Execution;

3) Support the test access port, namely TAP (Test Access Port) interface: EJTAG uses the TAP interface to transfer test data into or out of the CPU core. In addition to supporting standard JTAG commands, EJTAG also has its own newly defined commands.

4) Support software breakpoint instruction: SDBBP (Software Debug Breakpoint).

The EJTAG-based debugger can be used to debug monitoring programs and operating systems, and can analyze and determine CPU and motherboard faults through debugging diagnostic programs. It is an important tool for the smooth progress of CPU development. We proposed a scheme to use software to effectively control and use the EJTAG components on the target machine, and completed the design and implementation of the EJTAG-based cross-debugger, which greatly reduces the cost and has good portability (supporting different Microprocessor requires only a small amount of code modification).

Contents of the invention

The purpose of the present invention is to effectively control and use the EJTAG components on the target machine, and to realize the assembly-level and source code-level debugging functions running on the host machine in a convenient manner.

The cross-debugger implementation method based on the EJTAG component on the target machine is characterized in that: the processing process of the debugging command is all run on the host PC, and the processing process includes the following steps:

(1) According to the IEEE 1149.1 industrial standard formulated by the Joint Test Action Group of the IEEE Technical Committee Joint Test Action Group (JTAG), the test access port in the target machine MIPS CPU that has expanded the EJTAG components, that is, the Test Access Port (TAP interface) is as follows 5 EJTAG/JTAG signals are connected to the parallel I/O port of the host PC through signal lines:

TCK is the test clock signal, the direction is from the host PC to the target MIPS CPU;

TMS is the test mode selection signal, the direction is from the host PC to the target MIPS CPU;

TDI is the test data input signal, the direction is from the host PC to the target MIPS CPU;

TDO is the test data output signal, the direction is from the target MIPS CPU to the host PC;

TRST ^* is the test reset signal, which is an optional signal;

(2) Establish the following modules on the memory of the host PC:

For an assembly-level debugger running on Windows, it has the following modules:

a. The man-machine interface module adopts the graphical user interface GUI interface, and the display format of the debugged object code uses disassembled code, which provides the operation interface through the following functions:

OnOpenDocument(): Read the code in the disassembly display format into the memory, and set the values of the following variables:

store the length of each line of code,

store code,

The flag of the current row, 1 means the current row, 0 means not the current row,

Breakpoint table, store breakpoint information, 0 means no breakpoint, non-zero means there is a breakpoint, the corresponding number is the type of breakpoint,

Code line feature bit flag, 1 means code line, 0 means non-code line;

OnDownload(): Download the compiled code to the storage area starting from the specified address of the target machine;

OnDraw(): Display codes in different colors;

OnEditBrk(): Add a breakpoint and issue a breakpoint command to the interface;

OnEditMem(): Get and display the contents of the memory at the specified address;

OnEditReg(): Get and display the values of all registers;

OnRestart(): Send a restart command to restart the CPU;

OnSingleStep(): Send a single-step operation command and obtain the value of the register after the single-step operation;

OnRemoveBreakPoint(): remove the breakpoint;

Pack (): According to the RSP protocol, add a header and a tail for the content of the packet, and the RSP is the abbreviation of Remote Serial Protocol;

b. The debugging request processing module, which is the application program API of the upper human-machine interface module and the lower EJTAG/JTAG signal conversion and processing module, which converts the debugging request of the human-machine interface into a data packet conforming to the Remote Serial Protocol protocol, Send to the EJTAG/JTAG signal conversion and processing module, and then receive its response. The EJTAG/JTAG signal conversion and processing module has the following 9 types of debugging commands:

g command: read all registers,

G command: write all registers,

m command: read memory,

M command: write memory, R command: reset, start address executed after CPU interrupt is issued,

c command: continue, issue the starting address to continue execution after clearing the single-step flag,

s command: single-step operation, issue the starting address to start single-step execution,

z command: insert a breakpoint, set a certain address range as a breakpoint,

Z command: remove the breakpoint, cancel the breakpoint of a certain address range,

Correspondingly, the debugging request processing module sets the following functions used by each debugging request:

CallAPI(): Call CallR(), Callg(), CallG(), Callm(), CallM(), Callc( ), Calls(), Callz(), CallZ() functions, and then return the debugging results,

VerifyCommand(): Verify whether the instruction package is legal, and extract useful parts from it,

GetFirstChar(): Extract the first character of the instruction,

StrFreeCpy(): copy a string;

c. EJTAG/JTAG signal conversion and processing module, which converts the debugging command request in RSP format into JTAG signal, so that it is synchronized with the processing process of the target machine CPU, and returns the response information, corresponding to the above 9 types of debugging commands, it corresponds to It has the following interface functions:

CallR(): Execute the R command and return the result,

Callg(): Execute the g command and return the result,

CallG(): Execute the G command and return the result,

Callm(): Execute the m command and return the result,

CallM(): Execute the M command and return the result,

Callc(): Execute the c command and return the result,

Calls(): Execute the s command and return the result,

Callz(): Execute the z command and return the result,

CallZ(): Execute the Z command and return the result;

The implementation of these interface functions uses the following functions:

Pack(): According to the RSP protocol, add a header and tail to the contents of the packet,

SetWord(): Set the value of a 32-bit EJTAG register through EJTAG TAP, and the return value is 0;

GetWord(): Obtain the value of a 32-bit EJTAG register through the EJTAG TAP interface, and return the value of the register,

IsDigit(): Determine whether a character represents a hexadecimal digit, if yes, return value 1, otherwise return value,

SendSignal(): Send the signal to the EJTAG TAP interface through the parallel I/O port and receive feedback;

For the high-level language debugger running under the Linux system, the human-machine interface is realized by a common debugging program GDB, and the debugging command is passed to the above-mentioned EJTAG/JTAG signal conversion and processing module through the following EJTAG driver module;

d. The EJTAG driver module realizes the four functions of starting debugging, ending debugging, sending debugging requests, and reading debugging responses; it uses GDB to exchange debugging commands with the above-mentioned EJTAG/JTAG signal conversion and processing modules RSP protocol format, so the assembly-level debugger and the high-level language-level debugger share the EJTAG/JTAG signal conversion and processing module; the EJTAG driver uses a loadable kernel module: load the module with the insmod command, and unload it with the rmmod command This module; after the EJTAG module is loaded into the Linux system, a device file /dev/ejtag that meets the GDB serial port debugging requirements is established;

(3) The execution process of the assembly-level debugger running under the Windows system:

a. Load the debugged object code in the disassembled format into the memory through the function OnOpenDocument(),

b. Display the code in different colors through the function OnDraw(),

c. If necessary, download the code to the target machine through the function OnDownload(),

d. According to the needs, add breakpoints through the functions OnEditBrk(), OnEditMem(), OnEditReg(), OnRestart(), OnSingleStep(), OnRemoveBreakPoint(), obtain and display the contents of the specified address memory, and obtain and display the contents of all registers value, restart the CPU, send a single-step operation command and obtain the value of the register after the single-step operation, remove the breakpoint operation,

e. Choose to execute the debugging command multiple times to call the above function, and exit the debugger after executing the debugging command;

(4) The execution process of the high-level language debugger running under the Linux system:

a. Load the EJTAG driver module with the insmod command,

b. Realize the debugging operation that needs to be completed through the GDB command,

c. Exit GDB after executing the debugging operation,

d. Uninstall the EJTAG driver module with the rmmod command;

(5) For the assembly-level debugger running under the Windows system, the main function CallAPI() of the debugging request processing module uses the functions VerifyCommand() and GetFirstChar() to verify and check the validity of the debugging command, and then according to the debugging The commands respectively call the CallR(), Callg(), CallG(), Callm(), CallM(), Callc(), Calls(), Callz(), CallZ() functions given by the EJTAG/JTAG signal conversion and processing module , and then return the debugging result;

(6) Similar to the assembly-level debugger, for the high-level language-level debugger running under the Linux system, connect the EJTAG driver module of GDB so that the debugging commands issued by GDB call the CallR given by the EJTAG/JTAG signal conversion and processing module respectively (), Callg(), CallG(), Callm(), CallM(), Callc(), Calls(), Callz(), CallZ() and other functions, and then return the debugging results;

(7) For the assembly-level debugger running under the Windows system and the high-level language-level debugger running under the Linux system, the EJTAG/JTAG signal conversion and processing modules shared by the two give the following CallR(), Callg() , CallG(), Callm(), CallM(), Callc(), Calls(), Callz(), CallZ() function implementation:

(8) Processing procedure of function CallR():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. Set the EJTAG control register, that is, the reset flag bit Rocc in the ECR register to 0, and the EJTAG interrupt request bit EjtabBrk, the virtual memory segment dseg, that is, the debug segment effective bit ProbEn, and the debug exception vector address control bit ProbTrap are all set to 1;

c. Set the debug exception program counter DEBUG Exception Program Counter, which is the value of DEPC;

d. If there is an error in the execution process of b and c, that is, Rocc is set to 1, and the processor returns if it is not in the expected pause state, and an error flag is set;

e. return;

(9) Processing procedure of function Callg():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. Obtain the values of 32 general-purpose registers through the MIPS Store instruction;

c. Obtain the values of 27 cp0 registers through MIPS MFC0 and Store instructions;

d. If there is an error in the execution process of b and c, that is, Rocc is set to 1, and the processor returns if it is not in the expected pause state, and an error flag is set;

e. Return the contents of the general-purpose register and the cp0 register;

(10) Processing procedure of function CallG():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. Set the value of 27 cp0 registers through MIPS Load and MTC0 instructions;

c. Set the value of 32 general-purpose registers through the MIPS Load instruction;

d. If there is an error in the execution process of b and c, that is, Rocc is set to 1, and the processor returns if it is not in the expected pause state, and an error flag is set;

e. Return "OK";

(11) The processing of the function Callm():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. Load the contents of the memory into the general-purpose registers;

c. Obtain the value of the general-purpose register through the MIPS Store instruction;

d. If there is an error in the execution process of b and c, that is, Rocc is set to 1, and the processor returns if it is not in the expected pause state, and an error flag is set;

e. Return memory content;

(12) Processing procedure of function CallM():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. Obtain the value of the general-purpose register through the MIPS Load instruction;

c. Store the general-purpose register value into memory;

d. If there is an error in the execution process of b and c, that is, Rocc is set to 1, and the processor returns if it is not in the expected pause state, and an error flag is set;

e. Return "OK";

(13) The processing of the function Callc():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. Clear the SSt bit in the Debug register;

c. Set the value of the debug exception program counter DEPC;

d. Fill the MIPS DERET instruction into the DATA register of TAP;

e. Call Callg() to get the contents of the register;

f. If there is an error in the execution process of b, c, d, e, that is, Rocc is set to 1, the processor will return if it is not in the expected pause state, and set the error flag;

g. return the result;

(14) The processing of the function Calls():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. Clear the SSt bit in the Debug register;

c. Set the value of the debug exception program counter DEPC;

d. Fill the MIPS DERET instruction into the data register of TAP;

e. Call Callg() to get the contents of the register;

f. If there is an error in the execution process of b, c, d, e, that is, Rocc is set to 1, the processor will return if it is not in the expected pause state, and set the error flag;

g. return the result;

(15) Processing procedure of function Callz():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. The flag bit ASIDuse in the IBC field of the instruction breakpoint state register corresponding to the breakpoint is set to 0, BE is set to 1, if it is a data breakpoint, the flag bit BAL in the DBC field of the data breakpoint state register needs to be set Set to 0, BLM to 1;

c. Set the IBA field in the instruction breakpoint status register corresponding to the breakpoint;

d. Set the IBM domain in the instruction breakpoint status register corresponding to the breakpoint;

e. If there is an error in the execution process of b, c, and d, that is, Rocc is set to 1, and the processor is not in the expected pause state, it will return and set the error flag;

f. Return "OK";

(16) Processing procedure of function CallZ():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. The flag bit BE in the IBC field in the instruction breakpoint status register corresponding to the breakpoint is set to 0;

c. If there is an error in the execution process of b, that is, Rocc is set to 1, and the processor is not in the expected pause state, return and set the error flag;

d. Return "OK";

(17) The EJTAG/JTAG signal conversion and processing process described in (8) to (16) above converts the debugging command into a sequence of machine instructions, and then sends them to the CPU one by one through the TAP interface for execution, and retrieves the result content , and return after packaging; according to the control flow of TAP, during the processing of debugger commands, the reading and writing of TAP registers is carried out in the state of data register shift or instruction register shift, and serially at the falling edge of the test clock signal Shift out the test data, shift in the test data serially on the rising edge; shift in new data when writing the TAP register; save the shifted out data for return when reading the TAP register, and shift in new data at the same time;

(18) The completion of the debugging command needs to cooperate with the CPU of the target machine, and its basic working process is:

a. The debugger cyclically detects the PrAcc bit of the ECR register. If it is 0, continue to detect; if it is 1, it means that the processor has completed the requested operation and paused, and then go to the following step b;

b. The debugger determines the next action according to the running state:

·If it is waiting for CPU interrupt, it means that the CPU has entered the debugging exception processing, waiting for the code of exception processing; then put the specific instruction into the data register of TAP;

If the CPU has just executed a load or store instruction, and the operand address is located in the dseg segment, then the operand needs to be provided, that is, the load instruction is written to the data register of TAP, or the data is read, that is, the store instruction is from the TAP data register read);

c. The debugger sets the PrAcc position of the EJTAG control register ECR to 0, indicating that the debugger is ready and the CPU can continue;

d. turn to a;

(19) The results returned from (8) to (16) above will eventually be reflected on the user interface, and then the running process of the debugger is as described in (3) and (4).

The idea of the cross-debugger based on the EJTAG parts on the target machine realized according to the present invention is:

(1) The target machine suitable for this debugger is the CPU of the MIPS series architecture, and it extends the components supporting the EJTAG specification; see Figure 1, the part with the non-transparent filled background is the part added by EJTAG; only the CPU can execute the basic The instruction set (including MTC0/MFC0/LUI/LW/SW/LB/SB/DERET/ADD, etc.) can be used.

(2) 5 JTAG signals TCK (test clock Test Clock signal), TMS (test mode select Test Mode Select signal), TDI (test data input Test Data Input signal), TDO (test data output Test Data Output signal) and TRST ^* (test reset Test Reset Input ^* signal) are connected to the parallel port of the host computer through a simple line; Table 1 is the corresponding relationship between the JTAG signal and the I/O port data on the host computer.

Table 1 Comparison table of JTAG signal and I/O port data signal

JTAG signal I/O ports direction bit DB25 print port Pin No. Signal TMS BASE out 2 4 Data2 TCK BASE out 1 3 Data1 TDI BASE out 0 2 Data0 TDO BASE+1 In 4 13 select

Among them, BASE represents the base address of the parallel port used, and its default value is 0x378 on the PC. BASE+1 indicates the status port of the parallel port. The signal directions in the table are from the perspective of the host computer (PC). The reset signal TRST ^* is an optional signal, and its corresponding relationship is not listed in the table.

(3) The assembly-level debugging function runs on the Windows system, and the display format of the debugged target code uses disassembled code; the source code-level debugging function runs on the Linux system; Record format.

(4) The basic functions of the debugger involve breakpoint management (add, delete, list breakpoints), information query (check/modify the contents of the register, check/modify the data of the specified address), execution control (single step, continue, pause, reset) and code management (loading target code for local display, downloading target code to target machine, displaying source code), etc.

(5) The work of the debugger is a process of software and hardware working together. When the debugger starts, set the EJTAG control register, namely the reset flag bit Rocc in the ECR register, to 0, and the EJTAG interrupt request bit EjtabBrk, the effective bit ProbEn of the virtual memory segment dseg (debug segment), and the debug exception vector address control bit ProbTrap. 1. Make the CPU interrupt the program being executed and enter the debug mode. After the CPU enters the debugging mode, it executes the instructions sent by the debugger in turn, and exchanges relevant content with the debugger to complete the debugging work.

(6) The exchange format of debugging commands adopts the GDB remote serial protocol organized by GNU, that is, the RSP (Remote Serial Protocol,) format, so that assembly-level debugging running on Windows systems and high-level language-level debugging running on Linux systems can be shared for conversion and process code.

(7) The front-end of the high-level language debugger adopts GDB organized by GNU, and the back-end interfaces with the driver program and EJTAG/JTAG signal conversion and processing process. The EJTAG driver uses a loadable kernel module (loadable kernel module) approach.

The basic work process of the cross-debugger based on EJTAG realized according to the present invention is:

(1) The debugger circularly detects the PrAcc bit (pause flag, Process Access Pending) of the ECR register, if it is 0, continue to detect; if it is 1, it means that the processor has completed the requested operation and paused, turn to (2);

(2) The debugger determines the next action according to the running state:

If it is waiting for the CPU to interrupt, it means that the CPU has entered the debugging exception handling, waiting for the exception handling code; then put the specific instruction into the DATA register (data register) of TAP;

If the CPU has just executed the load/store instruction, and the operand address is located in the dseg segment, then you need to provide the operand (load instruction, write to the DATA register of TAP), or read the data (store instruction, from the DATA of TAP register read);

(3) The debugger sets the PrAcc position of the ECR to 0, indicating that the debugger is ready and the CPU can continue; (4) turn to (1).

The scheme of effectively controlling and using the EJTAG components on the target machine proposed by the present invention is embodied in the processing process of debugger commands. The processing process of each basic debugging command is basically similar, and the following uses "check the value of the register" as an example to illustrate:

(1) The user inputs the debugging request through the graphical user interface GUI or the command line: check the content of the register reg, and the command format is assumed to be print $reg;

(2) Analyze the user's debugging request command (print$reg);

Take the serial number no.of $reg of the reg register;

Packaging command: (request=ReadReg, index=no.of$reg, length=sizeof(int));

call(3);

turn(4);

(3) Analyze the debugging request (ReadReg);

Convert the processing of the request into a sequence of machine instructions; its main parts are as follows:

MTC0 $t1, DESAVE ; save $t1 register

LW $t1, HIGH(dseg) ; dseg is 0xFF200000

SW no.of$reg, 0($t1) ; the content is sent to the DATA register of TAP

MFC0 $t1, DESAVE ; restore $t1 register

Send the relevant command sequences to the CPU one by one through the TAP interface for execution, and retrieve the contents of the registers;

Package response: (response=success, length=sizeof(int), value=value of $reg);

return response;

(4) Get a response (response=success, length=sizeof(int), value=value of $reg);

Response converted into user-friendly way: $reg=0x12345678 (assuming value=0x12345678);

Display results to GUI or command line.

Reading and writing the TAP register is one of the core steps to complete the above process. According to the EJTAG specification, the TAP controller is a finite state machine, see Figure 3, its state is determined by TCK and TMS. The TAP controller samples the TMS signal on the rising edge of TCK, and then converts according to the state transition diagram. The TAP state transition diagram has 16 states, as shown in Figure 2-5. The number beside the arrow in the figure indicates whether the TMS signal is at high level or low level at the rising edge of TCK. The states identified in Figure 3 have the following meanings:

Test-Logic-Reset state: test logic reset state, it is the initial state, in this state, the boundary scan test logic is disabled; Run-Test/Idle state: the control register enters this state between two scan operations state, and remains in this state when the TMS input is '0', in this state, the contents of all instruction registers and test data registers remain unchanged; Select-DR-Scan state: determine the state of the scan data register, in this state In this state, all test data registers remain unchanged; Select-IR-Scan state: determine the state of the scan instruction register, in this state, all test data registers remain unchanged; Capture-DR state: decode the instruction register, determine to Scanned data register; Shift-DR state: In this state, the test data register is connected between TDI and TDO, and the data moves serially to TDO in each clock cycle; Exit1-DR state: It is a temporary intermediate state, in this state The data remains unchanged in the state; Pause-DR state: In this state, the movement of test data between TDI and TDO is temporarily stopped; Exit2-DR state: In this state, the data shifted in the Shift-DR state is refreshed Register; Update-DR state: In this state, the data shifted in the Shift-DR state is stored in the register specified by the instruction register; Capture-IR state: In this state, the instruction register is automatically loaded into the fixed vector (000012) ;Shift-IR state: In this state, the instruction register is connected between TDI and TDO, and the data moves serially to TDO in each clock cycle; Exit1-IR state: It is a temporary intermediate state, and in this state the data remains unchanged. Change; Pause-IR state: In this state, temporarily stop the movement of test data between TDI and TDO; Exit2-IR state: In this state, refresh the instruction register shifted in Shift-IR state; Update-DR State: In this state, the commands entered in the Shift-IR state take effect.

The reading and writing of the TAP register is carried out in the Shift-DR or Shift-IR state, and the data is serially shifted out from TDO on the falling edge of the TCK clock, and serially shifted in from TDI on the rising edge. Ignore the data shifted from TDO when writing the TAP register, and move new data in from TDI; when reading the TAP register, save the data shifted from TDO for return, and move it in from TDI at the same time to avoid destroying the contents of the register. Its main process is:

Drive TAP to shift to Shift-IR state

Write the register selection instruction into the instruction register IR of TAP

Drive TAP to shift to Shift-DR state

for (number of loops = 0; number of loops < number of digits in the data register; number of loops ++)

Move data out of TDO (to local variable)

if (is a read operation)

Save that data (to a local variable)

TDI (data shifted in) = data shifted out of TDO // avoid corrupting the contents of the register

else//is a write operation

TDI (shift data in) = data to be written to the register

Shift in data from TDI (to the MSB of the selected register)

end for

Drive TAP to transfer to Update-DR state

if (is a read operation)

Returns the contents of the read register

The completion of basic debugging commands needs to cooperate with the target CPU. Utilize software to effectively control and use the scheme of the EJTAG parts on the target machine that the present invention proposes, need the debugging exception response process of target machine CPU as follows:

When debug exception occurs, CPU judges the ProbTrap bit (debug exception vector address control bit) in ECR (EJTAG control register). If the bit is 0, jump to 0xBFC00480. This place is the debug exception program provided by the monitoring program or operating system. Finally execute DERET, the CPU returns to normal mode and continues to execute; if the bit is 1, jump to 0xFF200200. In debug mode, 0xFF200200 is located in a virtual memory segment dseg (debugsegment) that does not actually exist. At this time, the CPU stores the PC into the address register of the TAP, that is, the ADDRESS register, and then sets the relevant status bits, waiting for the instruction sent from the TAP to be executed. The specific process is:

(1) The processor sends the program counter, PC, to the ADDRESS register of the TAP;

(2) processor writes the sign bit of the ECR register in the TAP module: PrAcc=1; PRnW (pause kind: 0 expression reads, and 1 expression writes)=0 etc.;

(3) the processor does not stop detecting the PrAcc position, and if it is 1, it continues to wait; if it is 0, it enters (4);

(4) Put the instruction in the Data register of TAP into the IR register, and the processor executes in sequence according to the following situations:

If it is a DERET instruction, then turn to (6);

·If it is not a load/store instruction, execute it directly, and then go to (5);

·If it is a load/store instruction, but the operand address is not within dseg (0xFF000000-0xFF3F0000), execute it directly, and then go to (5);

·If it is a load command, the processing flow is:

Put the operand address into the ADDRESS register of TAP;

CPU suspends (set PrAcc=1 of ECR, PRnW=0 etc.), waits for debugger to provide operand;

The CPU loops to detect the PrAcc of the ECR until it is 0 and enters the next step;

Read the operand from the DATA register of TAP and execute the instruction;

turn(5);

·If it is a store command, the processing flow is:

Put the operand address and register content into the ADDRESS and DATA registers of TAP respectively;

CPU suspends (set PrAcc=1 of ECR, PRnW=1 etc.), waits for debugger to take away data;

CPU cycle detects the PrAcc of ECR, enters and turns (5) until being 0;

(5) The processor adds 4 to the PC value and turns to (1);

(6) Exit the debug mode and continue to execute the original code.

The present invention is characterized in that: the processing procedure of debugging command is all run on the host PC, and it comprises the following steps:

(1) The test access port in the target machine MIPS CPU that has expanded the EJTAG component is the Test Access Port referred to as the TAP interface, which is formulated by the IEEE Technical Committee Joint Test Action Group Joint Test Action Group referred to as JTAG under the IEEE1149.1 industry standard The above five JTAG signals are connected to the parallel I/O port of the host PC through signal lines:

TCK is the Test Clock signal of the test clock, and the direction is from the host PC to the target MIPS CPU;

TMS is the test mode selection Test Mode Select signal, the direction is from the host PC to the target MIPS CPU;

TDI is the test data input Test Data Input signal, the direction is from the host PC to the target MIPS CPU;

TDO is the test data output Test Data Output signal, the direction is from the target machine MIPS CPU to the host PC;

TRST ^* is the test reset Test Reset Input ^* signal, which is an optional signal.

(2) Establish the following modules on the memory of the host PC:

For an assembly-level debugger running on Windows, it has the following modules:

a. The man-machine interface module adopts the graphical user interface GUI interface, and the display format of the debugged object code uses disassembled code, which provides the operation interface through the following functions:

OnOpenDocument(): Read the code in the disassembly display format into the memory, and set the values of the following variables:

store the length of each line of code,

store code,

The flag of the current row, 1 means the current row, 0 means not the current row,

Breakpoint table, store breakpoint information, 0 means no breakpoint, non-zero means there is a breakpoint, the corresponding number is the type of breakpoint

Code line feature bit flag, 1 means code line, 0 means non-code line (comments, etc.)

OnDownload(): Download Motorola's S-record, that is, the code in S-Record format, to the storage area starting from the specified address of the target machine;

OnDraw(): Display codes in different colors;

OnEditBrk(): Add a breakpoint and issue a breakpoint instruction to the interface;

OnEditMem(); Get and display the content of the specified address memory;

OnEditReg(); Get and display the values of all registers;

OnRestart(); Send a restart command to restart the CPU;

OnSingleStep(); Send a single-step operation command and obtain the value of the register after the single-step operation;

OnRemoveBreakPoint(); remove the breakpoint;

Pack(): According to the RSP protocol, add a header and tail to the contents of the packet,

b. The debugging request processing module, which is the application program API of the upper human-machine interface module and the lower EJTAG/JTAG signal conversion and processing module, which converts the debugging request of the human-machine interface into a data packet conforming to the Remote Serial Protocol protocol, Send it to the EJTAG/JTAG signal conversion and processing module, and then receive its response. The latter has the following 9 types of debugging commands:

Callg(): Read all registers, referred to as g,

CallG(): Write all registers, referred to as G,

Callm(): read memory, referred to as m,

CallM(): write memory, referred to as M,

CallR(): reset, the starting address executed after the CPU interrupt is issued, referred to as R,

Callc(): Continue, issue the starting address to continue execution after clearing the single-step flag, referred to as c,

Calls(): single-step operation, issue the starting address to start single-step execution, referred to as s,

Callz(): Insert a breakpoint, set a certain address range as a breakpoint, referred to as z,

CallZ(): remove the breakpoint, cancel the breakpoint of a certain address range, referred to as Z;

Correspondingly, the debugging request processing module sets the following functions used by each debugging request:

CallAPI(): Execute the debugging commands sent from the man-machine interface through the EJTAG TAP interface. According to the debugging commands, the above 9 types of debugging commands given by the lower EJTAG/JTAG signal conversion and processing module are respectively called, and then the debugging results are returned.

VerifyCommand(): Verify whether the instruction package is legal, and extract useful parts from it,

GetFirstChar(): Extract the first character of the instruction,

StrFreeCpy(): copy a string;

c. EJTAG signal conversion and processing module, which converts the debugging command request in RSP format into JTAG signal, so that it is synchronized with the processing process of the target machine CPU, and returns the response information, corresponding to the debugging command that needs to be processed above, it is set correspondingly There are the following interface functions:

CallR(): Execute the R command and return the result,

Callg(): Execute the g command and return the result,

CallG(): Execute the G command and return the result,

Callm(): Execute the m command and return the result,

CallM(): Execute the M command and return the result,

Callc(): Execute the c command and return the result,

Calls(): Execute the s command and return the result,

Callz(): Execute the z command and return the result,

CallZ(): Execute the Z command and return the result.

The implementation of these interface functions uses the following functions:

Pack(): According to the RSP protocol, add a header and tail to the contents of the packet,

SetWord(): Set the value of a 32-bit EJTAG register through EJTAG TAP, and the return value is 0;

GetWord(): Obtain the value of a 32-bit EJTAG register through the EJTAG TAP interface, and return the value of the register,

IsDigit(): Determine whether a character represents a hexadecimal digit, if yes, return value 1, otherwise return value,

SendSignal(): Send the signal to the EJTAG TAP interface through the parallel port and receive feedback;

For the high-level language level debugger running under the Linux system, that is, the source code level debugger, its front end adopts GDB, and the back end interfaces with the above-mentioned EJTAG/JTAG signal conversion and processing module through the following EJTAG driver module:

d. The EJTAG driver module realizes the four functions of starting debugging, ending debugging, sending debugging requests, and reading debugging responses; the exchange of debugging commands between it and the above-mentioned EJTAG/JTAG signal conversion and processing modules naturally also uses GDB The RSP protocol format, which makes the assembly-level debugger and the original code-level debugger share the EJTAG/JTAG signal conversion and processing module; the EJTAG driver uses a loadable kernel module: use the insmod command to load the module, use rmmod command to uninstall the module; after the EJTAG module is loaded into the Linux system, a device /dev/ejtag is established to meet the requirements of GDB's serial port debugging;

(3) The execution process of the assembly-level debugger running under the Windows system:

a. Load the debugged object code in the disassembled format into the memory through the function OnOpenDocument(),

b. Display the code in different colors through the function OnDraw(),

c. If necessary, download the code to the target machine through the function OnDownload(),

d. According to the needs, add a breakpoint through the functions OnEditBrk(), OnEditMem(), OnEditReg(), OnRestart(), OnSingleStep(), OnRemoveBreakPoint(), and get and display the specified address

The content of the memory, get and display the value of all registers, restart the CPU, send a single-step operation command and get the value of the register after the single-step operation, remove the breakpoint operation,

e. Repeat the above process through the GUI, or exit the debugger;

(4) The execution process of the high-level language debugger running under the Linux system:

a. Load the EJTAG driver module with the insmod command,

b. Realize the debugging operation that needs to be completed through the GDB command,

c. Repeat step b, or exit GDB,

d. Uninstall the EJTAG driver module with the rmmod command;

(5) For the assembly-level debugger running under the Windows system, the main function CallAPI() of the debugging request processing module uses the function VerifyCommand( ) and GetFirstChar() to verify and check the validity of the package, and then call CallR() and Callg() respectively given by the EJTAG/JTAG signal conversion and processing module represented by Callxxx() according to the return value of GetFirstChar() , CallG(), Callm(), CallM(), Callc(), Calls(), Callz(), CallZ() and other functions, and then return the debugging results;

(6) Similarly, for a high-level language-level debugger running under the Linux system, connect the EJTAG driver module of GDB so that the debugging commands issued by GDB call the CallR() and Callg given by the EJTAG/JTAG signal conversion and processing module respectively. (), CallG(), Callm(), CallM(), Callc(), Calls(), Callz(), CallZ() and other functions, and then return the debugging results;

(7) For the assembly-level debugger running under the Windows system and the high-level language-level debugger running under the Linux system, the EJTAG/JTAG signal conversion and processing modules shared by the two give CallR(), Callg(), CallG (), Callm(), CallM(), Callc(), Calls(), Callz(), CallZ() and other functions, the implementation process uses the above-mentioned Pack(), SetWord(), GetWord(), IsDigit (), the function of SendSignal();

(8) Processing procedure of function CallR():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. Set the EJTAG control register, the reset flag bit Rocc in the ECR register, to 0, and the EJTAG

The interrupt request bit EjtabBrk, the virtual memory segment dseg (debug segment) valid bit ProbEn, and the debug exception vector address control bit ProbTrap are all set to 1;

c. Set the value of the DEBUG Exception Program Counter (DEBUG Exception Program Counter) DEPC;

d. If there is an error in the execution process of b and c (Rocc is set to 1, the processor is not in the expected pause state), then return and set the error flag;

e. return "";

(9) Processing procedure of function Callg():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. Obtain the value of 32 general-purpose registers through the Store command;

c. Obtain the values of 27 cp0 registers through MFC0 and Store instructions;

d. If there is an error in the execution process of b and c (Rocc is set to 1, the processor is not in the expected pause state), then return and set the error flag;

e. Return the contents of the general-purpose register and the cp0 register;

(10) Processing procedure of function CallG():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. Set the values of 27 cp0 registers through the Load and MTC0 instructions;

c. Set the value of 32 general-purpose registers through the Load command;

d. If there is an error in the execution process of b and c (Rocc is set to 1, the processor is not in the expected pause state), then return and set the error flag;

e. Return "OK";

(11) The processing of the function Callm():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. Load the memory content to the general-purpose register;

c. Obtain the value of the general-purpose register through the Store command;

d. If there is an error in the execution process of b and c (Rocc is set to 1, the processor is not in the expected pause state), then return and set the error flag;

e. Return memory content;

(12) Processing procedure of function CallM():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. Obtain the value of the general-purpose register through the Load command;

c. Store the general-purpose register value into the memory;

d. as b, c execution process is wrong (Rocc is set to 1, processor is not in the expected pause state), then return, and set error flag;

e. Return "OK";

(13) The processing of the function Callc():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. Clear the SSt bit in the Debug register;

c. Set the value of the debug exception program counter DEPC;

d. Fill in the DERET command;

e. Call Callg() to get the contents of the register;

f. If an error occurs during the execution of b, c, d, e (Rocc is set to 1, the processor is not in the expected pause state), return and set an error flag;

g. return the result;

(14) The processing of the function Calls():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. Clear the SSt bit in the Debug register;

c. Set the value of the debug exception program counter DEPC;

d. Fill in the DERET command;

e. Call Callg() to get the contents of the register;

f. If an error occurs during the execution of b, c, d, e (Rocc is set to 1, the processor is not in the expected pause state), return and set an error flag;

g. return the result;

(15) Processing procedure of function Callz():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. The flag bit ASIDuse in the IBC field of the instruction breakpoint state register corresponding to the breakpoint is set to 0, BE is set to 1, if it is a data breakpoint, the flag bit BAL in the DBC field of the data breakpoint state register needs to be set Set to 0, BLM to 1;

c. Set the IBA field in the instruction breakpoint status register corresponding to the breakpoint;

d. Set the IBM domain in the instruction breakpoint status register corresponding to the breakpoint;

e. If there is an error in the execution process of b, c, and d (Rocc is set to 1, the processor is not in the expected pause state), then return and set the error flag;

f. Return "OK";

(16) Processing procedure of function CallZ():

a. Check whether the instruction format is correct, if not, return and set an error flag;

b. The flag bit BE in the IBC field in the instruction breakpoint status register corresponding to the breakpoint is set to 0;

c. If there is an error in the execution process of b (Rocc is set to 1, the processor is not in the expected pause state), then return and set the error flag;

d. Return "OK";

(17) The EJTAG/JTAG signal conversion and processing process described in (8) to (16) above converts the corresponding debugging request into a sequence of machine instructions, and then sends them to the CPU one by one through the TAP interface for execution, and retrieves The result content is packaged and returned; according to the control flow of TAP, during the processing of debugger commands, the reading and writing of TAP registers is carried out in the Shift-DR/Shift-IR state, and the data is serially read from TDO is shifted out, and it is serially shifted in from TDI on the rising edge; when writing the TAP register, the data shifted out from TDO is ignored, and the new data is shifted in from TDI; when the TAP register is read, the data shifted out from TDO is saved for return, and at the same time it is rewritten Move in from TDI;

(18) The completion of the debugging command needs to cooperate with the CPU of the target machine, and its basic working process is:

a. The debugger cyclically detects the PrAcc bit of the ECR register. If it is 0, continue to detect; if it is 1, it means that the processor has completed the requested operation and paused, and then turn to b;

b. The debugger determines the next action according to the running state:

·If it is waiting for CPU interrupt, it means that the CPU has entered the debugging exception handling, waiting for the exception handling code; then put the specific instruction into the DATA register of TAP;

If the CPU has just executed the load/store instruction, and the operand address is located in the dseg segment, then you need to provide the operand (load instruction, write to the DATA register of TAP), or read the data (store instruction, from the DATA of TAP register read);

c. The debugger sets the PrAcc position of the ECR to 0, indicating that the debugger is ready and the CPU can continue;

d. turn to a;

(19) The results returned from (8) to (16) above will eventually be reflected on the user interface, and then the running process of the debugger is as described in (3) and (4).

Features and effects of the present invention

(1) There are no domestic reports on the design of EJTAG/JTAG-based debuggers

The implementation of on-chip debugging technology (mainly JTAG and BDM two types of specifications) is inseparable from the design of CPU or other processor chips, and the work of self-developed on-chip debugger has not been reported in China. Furthermore, the on-chip debugging technology based on EJTAG is only applicable to microprocessors with MIPS series architecture. However, only the THUMP series of Tsinghua University and the Godson series of the Institute of Computing Technology of the Chinese Academy of Sciences have carried out research work on microprocessors of this type of architecture in China. We developed The EJTAG-based cross-debugger is specially designed for the former, and plays an important role in the debugging of CPU, development board and system software.

(2) The processing of debugging commands and the mutual conversion of EJTAG signals run on the host computer

The scheme of using software to effectively control and use the EJTAG components on the target machine proposed by the present invention is embodied in that all the processing procedures of the debugger commands run on the host machine.

The existing foreign products based on EJTAG debugger need to add a hardware-realized emulator between the CPU and the host computer. Figure 17 is a schematic diagram of the BDI series EJTAG debugger of Abatron Company. Among them, the processing of debugging commands and the mutual conversion of EJTAG signals is a hardware-implemented simulation device BDI2000, which is located between the host machine debugger and the target machine. Convert it into BDM/EJTAG format and send it to the target machine; then receive the corresponding information of the target machine, convert it into the format required by the host machine debugger and return it to the host machine debugger. The domestic price of this product is more than 30,000 RMB. In comparison, in the EJTAG debugger we designed, the processing of debugging commands and the mutual conversion of EJTAG signals are also completed on the host computer, which is completely different for users in terms of performance/price ratio, adaptability and portability. s Choice.

(3) Good adaptability

According to this scheme, the host machine and the target machine are connected through a parallel port, and only 4 to 5 signal lines are needed. Only lead sockets are needed on the development board, and no additional logic needs to be implemented, so it has good adaptability and reduces costs at the same time.

In comparison, in Abatron's solution, the device BDI2000 is added between the host machine and the target machine. The host computer is connected to the BDI2000 through a serial port or Ethernet; when it is connected to the target computer, the requirements for the development board are not only to implement specific EJTAG lead logic, but also to provide support for power supply.

(4) Good portability

According to this scheme, the conversion of the debugging protocol is all completed on the host computer side, and only a small amount of code modification is required to support different target computer systems, which is obviously superior to the existing hardware emulator-based method in terms of portability.

In comparison, when Abatron's BDI2000 is transplanted to different target systems, the firmware needs to be updated, and the driver and configuration files will inevitably be changed, so the portability is not ideal. When researching this product, we found that it needs the close cooperation of Abatron's headquarters to satisfy our own CPU development, which cannot be achieved by its domestic agent. Because of this, we made up our minds to carry out the work of independent research and development based on EJTAG debugger.

Description of drawings

Figure 1. CPU with EJTAG capability.

Figure 2. Architecture of the debugger.

Figure 3. TAP state transition diagram.

Figure 4. Assembly-level debugging use case diagram.

Figure 5. Debug request processing flowchart.

Figure 6. EJTAG/JTAG signal conversion and processing.

Figure 7. Processing of the R instruction.

Figure 8. Processing of the g instruction.

Figure 9. Processing of G commands.

Figure 10. Processing of the m instruction.

Figure 11. Processing of the M command.

Figure 12. Processing of the c instruction.

Figure 13. Processing of the s instruction.

Figure 14. Processing of the z instruction.

Figure 15. Processing of the Z instruction.

Figure 16. Driver architecture for a source-level debugger.

Figure 17. Schematic diagram of the BDI series EJTAG debugger from Abatron.

Fig. 18 is the call relationship between the main modules of the scheme of the present invention (the left is the assembly-level debugging process under the Windows environment, and the right is the source-level debugging under the Linux environment).

Figure 19. The program flow of the HMI module in Figure 18.

Figure 20. The processing flow of the OnOpenDocument() function in Figure 19.

Figure 21. The processing flow of the OnDownload() function in Figure 19.

Figure 22. The processing flow of the OnDraw() function in Figure 19.

Figure 23. The processing flow of the OnEditBrk() function in Figure 19.

Figure 24. The processing flow of the OnEditMem() function in Figure 19.

Figure 25. The processing flow of the OnEditReg() function in Figure 19.

Figure 26. The processing flow of the OnRestart() function in Figure 19.

Figure 27. The processing flow of the OnSingleStep() function in Figure 19.

Figure 28. The processing flow of the OnRemoveBreakPoint() function in Figure 19.

Fig. 29 The calling relationship between the modules (functions) used in the debugging request processing module.

Figure 30 is the processing flow of the CallAPI() function in Figure 29.

Figure 31 Figure 29 in the VerifyCommand () function processing flow.

Figure 32 Flow chart of loading and unloading of EJTAG module: a. Loading b. Unloading.

Detailed ways

The architecture of the EJTAG-based cross-debugger implemented according to the present invention is as shown in Figure 2, wherein the solid line box part represents the main functional modules realized by itself: the assembly-level debugger includes three: man-machine interface module, debugging request processing module and EJTAG/JTAG signal conversion and processing module; the high-level language level debugger includes two: the EJTAG driver module connected to GDB and the EJTAG/JTAG signal conversion and processing module; among them, the EJTAG/JTAG signal conversion and processing module is the two shared.

The call relationship between modules is shown in Figure 18.

The main functions, working principles and processes of each module are introduced as follows:

(1) Assembly-level debugger man-machine interface module.

The assembly-level debugging is implemented in the Windows environment, and the GUI interface is adopted, which is easy and intuitive to operate. It provides the following operation interface (menu, or shortcut button): start debugging/reset CPU, download code to target machine, load source code; set breakpoint, delete breakpoint, view breakpoint; single-step execution, continue execution; View registers, modify registers; view memory, modify memory, etc. Its use case diagram is shown in Figure 4.

The disassembled code contains the address of the instruction, so the current line can be located according to the value of the instruction counter PC (Program Counter) and displayed on the interface. This is why we use disassembled code instead of assembly source code for debugging, because there is no address information in assembly source code.

(2) Debug request processing module.

The function of the debugging request processing module provides application program interface API functions such as breakpoint management, register and memory query and modification for the human-machine interface by calling the lower-layer EJTAG/JTAG signal conversion and processing module. It converts the debugging request of the man-machine interface into a data packet conforming to the Remote Serial Protocol protocol, sends it to the EJTAG/JTAG signal conversion and processing module, and then receives its response to complete the corresponding function. The processing flow of each function is similar, as shown in FIG. 5 .

(3) EJTAG/JTAG signal conversion and processing module.

As shown in the part below the dotted line in Figure 6, the main functions of this module include: reading and writing CPU registers, reading and writing target machine memory, and reading and writing TAP registers.

Table 2 shows the debugging command format transmitted from the man-machine interface and the debugging function processing module to the EJATAG signal conversion and processing module. Using the EJTAG TAP interface to realize the processing flow of nine commands (R, g, G, m, M, c, s, z, Z) of the debugger are shown in Fig. 7, Fig. 8, Fig. 9, Fig. 10, Fig. 11, respectively. Figure 12, Figure 13, Figure 14, and Figure 15; corresponding to 9 function modules CallR, Callg, CallG, Callm, CallM, Callc, Calls, Callz and CallZ respectively; error code E02 indicates an error during execution, and error code E03 indicates an instruction wrong format.

(4) Connect the EJTAG driver module of GDB. The front-end of the high-level language level debugger adopts GDB, and the back-end interfaces with the EJTAG/JTAG signal conversion and processing module through the driver program. The EJTAG driver takes the form of a loadable kernel module. When EJTAG debugging is needed, use the insmod command to load the module, and when it is not needed, use the rmmod command to unload the module to save system resources. After the EJTAG module is loaded into the Linux system, create a device /dev/ejtag, which meets the requirements of GDB's serial port debugging.

The main work of realizing the docking includes: (1) the interface between the driver program and the operating system; and (2) the interface that meets the requirements of GDB remote debugging. The architecture of its driver is shown in Figure 16.

Table 2 Debug command format passed to EJATAG signal conversion and processing module

Function command Read All regs G Write all regs Gxx (xx represents the contents of all general-purpose registers, arranged in ascending order of register numbers. Each 32-bit register occupies 4 bytes, arranged in order from high to low. Note: xx has a total of 4 ^* num bytes.) Read Memory maddr, length (addr represents the starting address, length represents the length in bytes, both values should be integer multiples of 4) Write Memory Maddr, length: xx (addr represents the starting address, length represents the length in bytes, both values should be integer multiples of 4, xx has a total of 4 ^* length bytes) restart Raddr (addr represents the starting address of CPU interrupt execution, which should be an integer multiple of 4) ContinueContinue caddr (addr represents the starting address to continue execution after clearing the single-step flag, which should be an integer multiple of 4, or it can be empty by default, indicating that the execution continues from the current address) Step single step saddr (addr represents the starting address to start single-step execution, which should be an integer multiple of 4, and can also be empty by default, indicating that single-step execution starts from the current address) insert breakpoint ztype, addr, length (type: 0-> instruction breakpoint #11-> instruction breakpoint #22-> data breakpoint write memory 3-> data breakpoint read memory 4-> data breakpoint read and write memory This instruction means Set a certain address range as a breakpoint, addr represents the starting address, and length represents the length of the range, both of which should be integer multiples of 4) remove breakpoint Ztype, addr, length (type: 0->command breakpoint #11->command breakpoint #22->data breakpoint write memory 3->data breakpoint read memory 4->data breakpoint read and write memory This instruction means Cancel the breakpoint of a certain address range, addr indicates the starting address, and length indicates the length of the range, both of which should be integer multiples of 4)

The structure and detailed design of each module are as follows:

(1) Assembly-level debugger man-machine interface

Figure 19 describes the program execution process. Firstly, the assembly source code is read by BOOL CdebuggerDoc::OnOpenDocument(LPCTSTR lpszPathName), and then the source code is displayed in a certain format by void CDebuggerView::OnDraw(CDC ^* pDC), and then various functions are implemented. Debug function. Each module (function) is described as follows:

Module (function) description: BOOL CDebuggerDoc::OnOpenDocument(LPCTSTR lpszPathName)

Function description: read the assembly source code into memory, do some processing, and set the values of the following variables:

int m_LineCount; // store the length of each line of code

char ^* m_charbuffer[MAXLINE]; //storage code

int m_currentLine[MAXLINE]; //current line flag, 1 means current

// row, 0 means not the current row

int m_breakPoint[MAXLINE]; //breakpoint table, store breakpoint information, 0 table

        //Shows no breakpoint, non-zero means there is a breakpoint, and the corresponding number is the breakpoint type

int m_codeLine[MAXLINE];. //code line flag, 1 means code line,

//0 means non-code lines (comments, etc.)

Parameter table: LPCTSTR lpszPathName: pointer to assembly file

Return value: Returns TRUE if it ends normally, otherwise returns FALSE

Processing flow: see Figure 20

Error message: TRUE --- read file successfully FALSE --- read file failed

Module (function) name: void CDebuggerView::OnDownload()

Function description: Get the content of the memory at the specified address and display it

Processing flow: see Figure 21

Module (function) description: void CDebuggerView::OnDraw(CDC ^* pDC)

Function description : Display the code, and display different colors according to whether it is the current line, whether it is a comment, whether it is a breakpoint, etc.

Parameter table: CDC ^* pDC: pointer to the current view class

Processing flow: see Figure 22

Module (function) description: void CDebuggerView::OnEditBrk()

Function description : Add a breakpoint, send a breakpoint command to the interface

Processing flow: see Figure 23

Module (function) name: void CDebuggerView::OnEditMem()

Function description : Get the content of the memory at the specified address and display it

Processing flow: see Figure 24

Module (function) name: void CDebuggerView::OnEditReg()

Function description : Get the values of all registers and display them

Processing flow: see Figure 25

Module (function) name: void CDebuggerView::OnRestart()

Function description     : Send a restart command to restart the CPU

Processing flow: see Figure 26

Module (function) name: void CDebuggerView::OnSingleStep()

Function description : Single-step operation, send a single-step command, and get the value of the register after the single-step operation.

Processing flow: see Figure 27

Remarks: The process of this function is relatively complicated, which is caused by the hardware characteristics of the target machine. The EJTAG standard

In , if there is a breakpoint in the current line, all instructions to continue the program will be executed without removing the breakpoint

Commands (including single step, continue, etc.) cannot be run, so before performing a single step, you need to add

The steps to remove the breakpoint. In the habit of using the program normally, after the breakpoint is run, it should still be

still exists, rather than disappearing, so the breakpoint is added in place after the single step to meet people's

's usage habits.

Module (function) name: void CDebuggerView::OnRemoveBreakPoint()

Function description: remove breakpoint

Processing flow: see Figure 28

(2) Debug request processing module.

FIG. 29 shows the calling relationship between modules (functions) used in the debugging request processing module. Among them: Callxxx() represents CallR(), Callg(), CallG(), Callm(), CallM(), Callc(), Calls(), Callz(), CallZ() 9 functions, because their execution process is roughly Similarly, the call function is the same (see EJTAG/JTAG signal conversion and processing module), so writing Callxxx() is convenient for expression. The processing flow of Callxxx() is described in the EJTAG/JTAG signal conversion and processing module. Other modules (functions), including the modules (functions) used by Callxxx() are described as follows:

Module (C function) name: char ^* CallAPI(char ^* command)

Function description : Execute the debugging commands sent from the man-machine interface through the EJTAG TAP interface,

  Return the execution result to the machine interface

Parameter table : command: the debugging command received from the man-machine interface

Return value : the debugging result returned to the man-machine interface

Processing flow: see Figure 30

Error message: E00----command package damaged E01----unrecognized command

Module (C function) name: int VerifyCommand(char ^* &command)

Function description : Verify whether the instruction package is legal, and extract useful parts from the instruction package

Parameter table : command: command package, after VerifyCommand() ends, the header and tail of the package are removed (for example, the command package

$Rbfc00000#? Change to Rbfc00000 after VerifyCommand())

return value : 0

Processing flow: see Figure 31

Processing flow:

Error message: -1 indicates that the instruction package is illegal

Module (C function) name: char GetFirstChar(char ^* &command)

Function description : Take out the first character of the instruction

Parameter table : command: command, after GetFirstChar() ends, the first character is removed (for example, command

Rbfc00000 becomes bfc00000 after GetFirstChar())

Return value : the first character of command

Module (C function) name: char ^* StrFreeCpy(char ^* s, int first, int length)

Function description : Copy a substring of the string s whose length is length starting from first, and return

Parameter table: s: string, first: integer, length: integer

Return value : A substring of string s whose length is length starting from first

Module (C function) name: int IsDigit(char c)

Function description : Determine whether a character represents a hexadecimal number

Parameter table : c: the character to be judged

Return value : 1

Error message : 0----This character does not represent a hexadecimal number

Module (C function) name: char ^* pack(char ^* content)

Function description : Packing function, adding header and tail to the contents of the package, the format of the package complies with the Remote Serial Protocol;

(It is also used when generating the Command function of the CdebuggerView class)

Parameter table : content: the content of the package

Return value : the packaged content

Module (C function) name: int GetWord(int IR)

Function description : Obtain the value of a 32-bit EJTAG register through the EJTAG TAP interface

Parameter table : IR: IR corresponding to the EJTAG register

Return value : the value of the register

Processing flow: Set the signal format and store it in the character array, and send it from the parallel port to the EJTAG TAP through the SendSignal() function

Interface

Module (C function) name: int SetWord(int IR)

Function description : Obtain the value of a 32-bit EJTAG register through the EJTAGTAP interface

Parameter table : IR: IR corresponding to the EJTAG register

return value : 0

Processing flow: Set the signal format and store it in the character array, and send it from the parallel port to the EJTAG TAP through the SendSignal() function

Interface

Module (C function) name: int SendSignal(int lenOfSignal, char ^* signal)

Function description : Send the signal to the EJTAG TAP interface through the parallel port and receive feedback

Parameter table : IR: IR corresponding to the EJTAG register

return value : 0

Processing flow: EJTAG TAP interface feedback value

Note: The return value of the command execution result and error information is packed by the pack() function before returning to the HMI

(3) EJTAG/JTAG signal conversion and processing module.

See Figure 7, Figure 8, Figure 9, Figure 10, Figure 11, Figure 12, Figure 13 for the processing flow of the nine commands (R, g, G, m, M, c, s, z, Z) to be processed , Figure 14, Figure 15; respectively correspond to 9 function modules CallR, Callg, CallG, Callm, CallM, Callc, Calls, Callz and CallZ; the corresponding function interface definitions are:

Module (C function) name: char ^* CallR(char ^* command)

Function description : Execute the R command and return the result

Parameter table : command: command (excluding the first character)

Return value : Execution succeeded ---- return ""

Processing flow: see Figure 7

Error message: E02----Error during execution E03----Instruction format error

Module (C function) name: char ^* Callg(char ^* command)

Function description : Execute the g command and return the result

Parameter table : command: command (excluding the first character)

Return value : register contents (general purpose registers and cp0)

Processing flow: see Figure 8

Error message: E02----Error during execution E03----Instruction format error

Module (C function) name: char ^* CallG(char ^* command)

Function description   : Execute the G command and return the result

Parameter table : command: command (excluding the first character)

return value : OK

Processing flow: see Figure 9

Error message: E02----Error during execution E03----Instruction format error

Module (C function) name: char ^* Callm(char ^* command)

Function description : Execute the m command and return the result

Parameter table : command: command (excluding the first character)

return value : OK

Processing flow: see Figure 10

Error message: E02----Error during execution E03----Instruction format error

Module (C function) name: char ^* CallM(char ^* command)

Function description   : Execute the M command and return the result

Parameter table : command: command (excluding the first character)

return value : OK

Processing flow: see Figure 11

Error message: E02----Error during execution E03----Instruction format error

Module (C function) name: char ^* Callc(char ^* command)

Function description : Execute the c command and return the result

Parameter table : command: command (excluding the first character)

Return value : See Table 2

Processing flow: see Figure 12

Error message: E02----Error during execution E03----Instruction format error

Module (C function) name: char ^* Calls(char ^* command)

Function description : Execute the s command and return the result

Parameter table : command: command (excluding the first character)

Return value: see Table 2

Processing flow : See Figure 13

Error message: E02----Error during execution E03----Instruction format error

Module (C function) name: char ^* Callz(char ^* command)

Function description : Execute the z command and return the result

Parameter table : command: command (excluding the first character)

return value : OK

Processing flow: see Figure 14

Error message: E02----Error during execution E03----Instruction format error

Module (C function) name: char ^* CallZ(char ^* command)

Function description : Execute the Z command and return the result

Parameter table : command: command (excluding the first character)

return value : OK

Processing flow: see Figure 15

Error message: E02----Error during execution E03----Instruction format error

(4) Connect the EJTAG driver module of GDB.

The driver implements four functions: start debugging, end debugging, send debugging request, and read debugging response. The processing process is as follows:

(a) Start debugging:

Apply for I/O address range from Linux Kernel

Reset the target machine

Read the number of hardware breakpoints and software breakpoints implemented by the CPU

(b) End debugging:

free I/O address range

(c) Issue a debug request:

Verify and analyze debugging requests

Handle debug requests

The processed result is put into the result buffer

(d) Read the debug response:

Does the loop test have results

if(result already exists)

Read processing result from result buffer

The interface between the driver program and the operating system is the loading and unloading of the EJTAG module, as shown in Figure 32.

Claims (1)

1. the intersection debugger implementation method of the EJTAG parts on the based target machine, it is characterized in that: the processing procedure of debug command is all to move on host's PC, and this processing procedure comprises following steps:

(1) be called for short the IEEEE1149.1 industrial standard that JTAG formulates according to the Joint Test Action Group of combined testing action group of IEEE technical committee, making test access port among the target machine MIPS CPU that has expanded the EJTAG parts is that following 5 EJTAG/JTAG signals that Test Access Port is called for short the TAP interface link to each other with parallel I/O port of host PC by signal wire:

TCK is a test clock signals, direction from host's PC to target machine MIPS CPU;

TMS is that test mode is selected signal, direction from host's PC to target machine MIPS CPU;

TDI is an input signal of test data, direction from host's PC to target machine MIPS CPU;

TDO is a test data output signal, direction from target machine MIPS CPU to host's PC;

TRST ^*Be test reset signal, this signal is optional signal;

(2) on the storer of host's PC, set up with lower module:

For the assembly level debugger that operates under the Windows system, it has with lower module:

A. human-computer interface module adopts the graphical user interface gui interface, and the display format of debugged object code uses the dis-assembling code, and it is by providing operation interface with minor function:

OnOpenDocument (): the code of dis-assembling display format is read in internal memory, and set the value of following variable:

Store the length of every line code,

Storage code,

Current line Q-character flag, 1 is expressed as current line, the non-current line of 0 expression,

Breakpoint table, store breakpoint information, the no breakpoint of 0 expression, it is the breakpoint type that non-0 expression has breakpoint, respective digital,

Code line Q-character flag, 1 is expressed as code line, the non-code line of 0 expression;

OnDownload (): the storage area that the code that downloading collects obtains begins to the target machine assigned address;

OnDraw (): with the different colours reveal codes;

OnEditBrk (): add breakpoint, send break-poing instruction to interface;

OnEditMem (): the content that obtains and show the assigned address internal memory;

OnEditReg (): the value that obtains and show all registers;

OnRestart (): send instruction of restarting, restart CPU;

OnSingleStep (): send the single-step operation order, and obtain the value of single-step operation late register;

OnRemoveBreakPoint (): remove breakpoint;

Pack (): according to the RSP agreement, acquire packet header bag tail for the content of bag, described RSP is the abbreviation of Remote SerialProtocol;

B. debug request processing module, it is human-computer interface module and the EJTAG/JTAG conversion of signals of lower floor and the application A PI of processing module on upper strata, it is converted into the debugging request of man-machine interface the packet that meets Remote Serial Protocol agreement, send to EJTAG/JTAG conversion of signals and processing module, receive its response again, this EJTAG/JTAG conversion of signals and processing module are provided with following 9 class debug commands:

The g order: read all registers,

The G order: write all registers,

The m order: memory read,

The M order: memory write, the R order: reset, send the start address of having no progeny among the CPU and carrying out,

C order: continue, send to remove and continue the start address carried out behind the single step sign,

The s order: single-step operation, send the start address that the beginning single step is carried out,

The z order: insert breakpoint, setting a certain address realm is breakpoint,

The Z order: remove breakpoint, cancel the breakpoint of a certain address realm,

Correspondingly, the debugging request processing module is set the used function of following each debugging request:

CallAPI (): according to the debug command of transmitting from man-machine interface, call the CallR () that EJTAG/JTAG conversion of signals and processing module provide respectively, Callg (), CallG (), Callm (), CallM (), Callc (), Calls (), Callz (), CallZ () function returns debug results again

VerifyCommand (): whether checking instruction bag is legal, and therefrom extracts useful part,

GetFirstChar (): extract first character of instruction,

StrFreeCpy (): copy a string;

C.EJTAG/JTAG conversion of signals and processing module, it is converted to the JTAG signal to the debug command request of RSP form, and feasible processing procedure with target machine CPU is synchronous, and returns response message, corresponding to above-mentioned 9 class debug commands, it is provided with following interface function accordingly:

CallR (): carry out the R order, return results,

Callg (): carry out the g order, return results,

CallG (): carry out the G order, return results,

Callm (): carry out the m order, return results,

CallM (): carry out the M order, return results,

Callc (): carry out the c order, return results,

Calls (): carry out the s order, return results,

Callz (): carry out the z order, return results,

CallZ (): carry out the Z order, return results;

The realization of these interface functions has been used as minor function:

Pack (): according to the RSP agreement, for the content of bag is acquired packet header bag tail,

SetWord (): by EJTAG TAP the value of 32 EJTAG registers is set, rreturn value is 0;

GetWord (): obtain the value of 32 EJTAG registers by EJTAG TAP interface, the value of return register,

IsDigit (): judging whether a character represents a hexadecimal digit, is rreturn value 1 then, non-then rreturn value,

SendSignal (): send signal to EJTAG TAP interface and accept feedback by parallel I/O port;

For the higher level lanquage level debugger that operates under the linux system, man-machine interface realizes that by a kind of debugged program GDB commonly used debug command passes to above-mentioned EJTAG/JTAG conversion of signals and processing module by following EJTAG driver module;

The d.EJTAG driver module has been realized beginning debugging, has finished debugging, has sent the debugging request, has been read four functions of debugging response; The exchange of the debug command of carrying out between it and above-mentioned EJTAG/JTAG conversion of signals and the processing module is the RSP protocol format that adopts GDB, so assembly level debugger and higher level lanquage level debugger sharing E JTAG/JTAG conversion of signals and processing module; This EJTAG driver adopts the mode of the kernel module that can load: order this module of packing into insmod, with this module of rmmod order unloading; After the EJTAG module is packed linux system into, set up device file/dev/eitag that an AccessPort that meets GDB requires;

(3) run on the implementation of the assembly level debugger under the Windows system:

A. pass through the debugged object code graftabl of function OnOpenDocument () with the dis-assembling form,

B. pass through function OnDraw () with the different colours reveal codes,

C. if need, download code to target machine by function OnDownload (),

D. as required, by function OnEditBrk (), OnEditMem (), OnEditReg (), OnRestart (), OnSingleStep (), OnRemoveBreakPoint () realize adding breakpoint, obtain and show the content of assigned address internal memory, obtain and show the value of all registers, restart CPU, send the single-step operation order and obtain the value of single-step operation late register, remove the operation of breakpoint

E. select to carry out debug command for many times and call, withdraw from debugger after executing debug command with superior function;

(4) run on the implementation of the higher level lanquage level debugger under the linux system:

A. order the EJTAG driver module of packing into insmod,

B. realize the debugging operations that need finish by GDB order,

C. withdraw from GDB after executing debugging operations,

D. with rmmod order unloading EJTAG driver module;

(5) for the assembly level debugger that runs under the Windows system, the principal function CallAPI () of debugging request processing module, utilize function VerifyCommand () and GetFirstChar () that verification and legitimacy check are carried out in debug command, and then call the CallR () that EJTAG/JTAG conversion of signals and processing module provide respectively according to debug command, Callg (), CallG (), Callm (), CallM (), Callc (), Calls (), Callz (), CallZ () function returns debug results again;

(6) similar with the assembly level debugger, for the higher level lanquage level debugger that runs under the linux system, connect debug command that the EJTAG driver module of GDB sends GDB and call the CallR () that EJTAG/JTAG conversion of signals and processing module provide, Callg () respectively, CallG (), Callm (), CallM (), Callc (), Calls (), Callz (), CallZ functions such as () returns debug results again;

(7) for running on the assembly level debugger under the Windows system and running on higher level lanquage level debugger under the linux system, EJTAG/JTAG conversion of signals and processing module that the two is shared provide following CallR (), Callg (), CallG (), Callm (), CallM (), Callc (), Calls (), Callz (), the realization of CallZ () function:

(8) processing procedure of function C allR ():

A. check whether order format is correct, then return as if incorrect, and put error flag;

B. be that reseting mark position Rocc in the ECR register puts 0 with the EJTAG control register, and EJTAG interrupt request position EjtabBrk, virtual memory section dseg, promptly debug segment significance bit ProbEn and debugging exception vector address control bit ProbTrap all put 1;

C., it is the value of DEPC that debugging exception procedure counter DEBUG Exception Program Counter is set;

D. as b, the c implementation is made mistakes, and promptly Rocc is changed to 1, and processor is not in the halted state of expection and then returns, and puts error flag;

E. return;

(9) processing procedure of function C allg ():

A. check whether order format is correct, then return as if incorrect, and put error flag;

B. obtain the numerical value of 32 general-purpose registers by MIPS Store instruction;

C. obtain the numerical value of 27 cp0 registers by MIPS MFC0 and Store instruction;

D. as b, the c implementation is made mistakes, and promptly Rocc is changed to 1, and processor is not in the halted state of expection and then returns, and puts error flag;

E. return the content of general-purpose register and cp0 register;

(10) processing procedure of function C allG ():

A. check whether order format is correct, then return as if incorrect, and put error flag;

B., the numerical value of 27 cp0 registers is set by MIPS Load and MTC0 instruction;

C., the numerical value of 32 general-purpose registers is set by MIPS Load instruction;

D. as b, the c implementation is made mistakes, and promptly Rocc is changed to 1, and processor is not in the halted state of expection and then returns, and puts error flag;

E. return " OK ";

(11) processing procedure of function C allm ():

A. check whether order format is correct, then return as if incorrect, and put error flag;

B. memory content is encased in general-purpose register;

C. obtain the numerical value of general-purpose register by MIPS Store instruction;

D. as b, the c implementation is made mistakes, and promptly Rocc is changed to 1, and processor is not in the halted state of expection and then returns, and puts error flag;

E. return memory content;

(12) processing procedure of function C allM ():

A. check whether order format is correct, then return as if incorrect, and put error flag;

B. obtain the numerical value of general-purpose register by MIPS Load instruction;

C. general-purpose register numerical value is deposited in the internal memory and goes;

D. as b, the c implementation is made mistakes, and promptly Rocc is changed to 1, and processor is not in the halted state of expection and then returns, and puts error flag;

E. return " OK ";

(13) processing procedure of function C allc ():

A. check whether order format is correct, then return as if incorrect, and put error flag;

B. remove the SSt position in the Debug register;

C., the value of debugging exception procedure counter DEPC is set;

D. MIPS DERET instruction is inserted the DATA register of TAP;

E. call Callg () and obtain content of registers;

F. as b, c, d, the e implementation is made mistakes, and promptly Rocc is changed to 1, and processor is not in the halted state of expection and then returns, and puts error flag;

G. return results;

(14) processing procedure of function C alls ():

A. check whether order format is correct, then return as if incorrect, and put error flag;

B. remove the SSt position in the Debug register;

C., the value of debugging exception procedure counter DEPC is set;

D. MIPS DERET instruction is inserted the data register of TAP;

E. call Callg () and obtain content of registers;

F. as b, c, d, the e implementation is made mistakes, and promptly Rocc is changed to 1, and processor is not in the halted state of expection and then returns, and puts error flag;

G. return results;

(15) processing procedure of function C allz ():

A. check whether order format is correct, then return as if incorrect, and put error flag;

B. the zone bit ASIDuse in the IBC territory in the instruction breakpoint status register of breakpoint correspondence is changed to 0, and BE is changed to 1, if data breakpoint, the zone bit BAL that also need be provided with in the data breakpoint status register DBC territory is changed to 0, and BLM is changed to 1;

C., IBA territory in the instruction breakpoint status register of breakpoint correspondence is set;

D., IBM territory in the instruction breakpoint status register of breakpoint correspondence is set;

E. as b, c, the d implementation is made mistakes, and promptly Rocc is changed to 1, and processor is not in the halted state of expection and then returns, and puts error flag;

F. return " OK ";

(16) processing procedure of function C allZ ():

A. check whether order format is correct, then return as if incorrect, and put error flag;

B. the zone bit BE in the IBC territory in the instruction breakpoint status register of breakpoint correspondence is changed to 0;

C. make mistakes as the b implementation, promptly Rocc is changed to 1, and processor is not in the halted state of expection, then returns, and puts error flag;

D. return " OK ";

(17) above-mentioned (8) to (16) described EJTAG/JTAG conversion of signals and processing procedure are converted into the sequence of a machine instruction to debug command, give CPU item by item by the TAP interface then and carry out, and fetch resultant content, return after packing; Control flow according to TAP, in debugger process of commands process, the read-write of TAP register is carried out in data register shift or order register displaced condition, serially test data is shifted out at the test clock signals negative edge, serially test data is moved at rising edge; When writing the TAP register, move into new data; The data that preservation is shifted out when reading the TAP register move into new data simultaneously for returning;

(18) finishing of debug command need cooperate with target machine CPU, and its groundwork process is:

A. the PrAcc position of debugger cycle detection ECR register, if 0, continue to detect; If 1, the expression processor is finished requested operation and is suspended, and changes following steps b;

B. debugger determines next step action according to the state of operation:

If waiting for CPU is interrupted, expression CPU has entered the debugging exception and has handled, and waits for the code that exception is handled; So specific instruction is put into the data register of TAP;

Pack into or storage instruction if just allowed CPU carry out, and operand address is positioned at the dseg section, needs to provide operand so, the instruction of promptly packing into is write toward the data register of TAP, perhaps sense data, promptly storage instruction is read from the data register of TAP);

C. debugger is the PrAcc position of EJTAG control register ECR 0, and the expression debugger is ready, and CPU can continue;

D. change a;

(19) above-mentioned (8) finally can be reflected to user interface to (16) return results, and the operational process of debugger is as described in (3), (4) afterwards.

Images