Abstract: This paper designs and implements a debugging tool for EmJTAG-based ARM embedded systems. It first defines a lightweight remote debugging protocol, EmRDI, for the interaction between a PC and an EmJTAG-based ARM target board. Then, it describes the technical details of implementing a protocol converter, EmJTAG, using STMicroelectronics' ST72651 chip. The function of EmJTAG is to convert debugging commands from the PC into JTAG timing signals on the target board, thereby controlling both the PC and the target board. Keywords: EmRDI, EmJTAG, boundary scan, remote debugging, protocol converter Introduction The general development process of an ARM embedded system is as follows: first, program source code is written on a PC; then, an ARM cross-compiler compiles and links the code to generate an object file; then, the object file is converted into binary code that can be downloaded to the target machine for debugging and execution; finally, the successfully debugged binary file is embedded in the target machine. The most crucial step in this process is debugging the program running on the target machine from the PC. This requires remote debugging, i.e., running debugger software on the PC and the program being debugged on the target machine. This paper describes a remote debugging system that utilizes the reliability of USB bulk transfers to encapsulate EmRDI remote debugging protocol messages within USB data packets. The protocol converter EmJTAG then converts the received USB data packets into appropriate JTAG signals to control and debug the ARM core. The EmJTAG protocol converter is implemented using STMicroelectronics' ST72651 chip plus an interface driver chip 74LVC244. The ST72651 integrates a USB module and a Data Transfer Coprocessor (DTC). Programming the DTC generates boundary scan sequences to control the ARM core, thus producing the corresponding JTAG signals. The paper ultimately implements PC-based debugging functionality for the ARM core target machine: the PC's debugger software can download programs to the target machine, control the code's single-step/full-speed execution or stop in real time, and set breakpoints and watchpoints, read and write registers/memory, etc. 1 System Composition and Principle As shown in Figure 1, the entire debugging system consists of three parts: a PC (debugger), a protocol converter (EmJTAG), and a target board (based on an ARM core). The purpose of debugging is to enable single-step or full-speed operation of the target board from a PC, and to view or modify register and memory values ​​in real time. The system design implements a remote debugging protocol, EmRDI, which uses a point-to-point connection and interacts in a request-response manner. Debug requests are issued by the debugger software on the PC and transmitted via the USB bus to the protocol converter EmJTAG. EmJTAG interprets the protocol request, performs the corresponding operation, and sends it back to the PC in the form of USB data packets (i.e., the response process). The EmRDI protocol defines the following debug requests: read/write core registers, read/write memory, set/clear hardware breakpoints, set/clear software breakpoints, set/clear data watchpoints, reset, stop running, full-speed/single-step operation, and return processor status/device identifier. Verification shows that the combination of these requests enables the PC to debug and control the ARM core on the target machine. The EmRDI protocol request format (16 bytes) is as follows: The EmRDI protocol response format (8 bytes) is as follows: ARM core chips generally conform to the JTAG specification and have boundary scan functionality. These chips integrate a JTAG circuit structure. The JTAG circuit consists of a TAP (Test Access Port), a TAP controller, an instruction register, and a test data register. Additionally, the ARM7TDMI core includes an EmbeddedICE macrocell that provides in-circuit debugging support. EmJTAG connects to the PC via a USB bus, while the connection to the target board follows the JTAG debug interface standard. The JTAG specification uses a basic structure called a "boundary scan unit." The boundary scan unit links the JTAG circuit to the processor logic circuit. It allows an input signal to be loaded into the processor logic without affecting other circuits, and it can also sample the processor logic's output signal into the boundary scan unit. Several boundary scan units constitute the boundary scan register (BSR), also known as a "boundary scan chain." Data in the boundary scan register is serially shifted in and out through the TDI and TDO pins of the JTAG interface. The PC needs to implement: the USB driver and debugger software for EmJTAG. The EmJTAG itself needs to implement: USB firmware and a boundary scan program for generating JTAG signals. 2. Hardware Design and Implementation The hardware part of the system mainly refers to the implementation of the protocol converter EmJTAG. The function of the protocol converter is to receive remote debugging protocol information sent by the debugger software on the PC, convert it into JTAG timing signals and send them to the target board, and then return the feedback information or data from the target board to the debugger software on the PC. EmJTAG uses the ST72651 chip from STMicroelectronics (ST), and its block diagram is shown in Figure 2. It integrates a full-speed (12 Mbps) USB interface module, a data transfer coprocessor (DTC) with a clock frequency of 24 MHz, 32 KB of program memory, 5 KB of RAM, hardware I2C and SPI interfaces, and up to 47 programmable I/O ports; the operating voltage is 2.7–5.5 V, and it is directly powered by USB. For communication with the PC, the USB interface only requires a pull-up resistor on the DP pin to enable the PC to recognize the USB device. The DTC module generates four clock signals as JTAG clock signals (TDI, TDO, TMS, and TCK), which are led out from the I/O port. An external interface driver chip 74LVC244 is added to connect these four signals to the standard JTAG interface. The TAP controller reset signal nTRST and the system reset signal nSRST are directly controlled by the I/O logic. EmJTAG uses USB power supply, and an indicator light BUSY is connected to the TCK pin to show whether the system is busy. The interface driver chip 74LVC244 generates 3.3V to provide the voltage through its internally integrated voltage calibrator. 3 Software Design and Implementation The software part mainly includes: debugger software on the PC, PC-side driver for the EmJTAG protocol converter, and firmware program in EmJTAG. 3.1 The debugger software on the PC uses VC++ 6.0 MFC. Its main function is to communicate with the EmJTAG PC driver, sending debug commands to the EmJTAG via the USB bus. 3.2 The EmJTAG PC driver uses Driverstudio 3.1 to develop a USB driver for Windows, enabling data interaction between the EmJTAG and PC applications. 3.3 The firmware in the EmJTAG is developed using STMicroelectronics' (ST) development tool STVD7 for InDART STX. This part is also the most important part of the debugging system, namely how to generate JTAG timing signals to control the ARM core. The firmware in the EmJTAG is implemented in several modules. 3.3.1 DTC Software Plug-in Program Module The DTC functional block diagram is shown in Figure 3. The DTC is a data transfer coprocessor integrated within the ST72651, and also a general-purpose serial/parallel communication interface. By changing the plug-in program running within it, the DTC can easily complete different high-speed data transfer operations. The plug-in program (maximum 256 bytes) is initially stored in the ST72651's Flash memory. The program running on the chip loads the plug-in program into the DTC SW RAM and then controls the DTC to execute it. The ST7 core can also read and write to the DTC's data transfer buffer, therefore an arbitration circuit is needed to prevent conflicts when the ST7 core and DTC access this buffer. The DTC has a simple instruction set. The ST7 core controls the DTC's operation through the DTC control register DTCCR, queries the DTC's status through the DTC status register DTCSR, and changes the DTC's operation pointer through the DTC pointer register DTCPR. The DTC has four operating states: Idle, RAMload, Running, and Pointer Change. The transitions between these four states are achieved by changing the RUN, INIT, and LOAD bits of the DTCCR register. The steps to load the plug-in program into the DTC SW RAM are as follows: ◆ Clear the RUN bit of the DTCCR register to put the DTC into the IDLE state and stop the DTC; ◆ Set the LOAD bit of the DTCCR register to put the DTC into the RAMLOAD state to allow writing to the DTC RAM; ◆ Copy the plug-in program into the DTC SW RAM; ◆ Clear the LOAD bit of the DTCCR register to return the DTC to the IDLE state and restore write protection to the DTC RAM. The steps to make the DTC run the plug-in program in its RAM (i.e., DTC SW RAM) are as follows: ◆ Clear the RUN bit of the DTCCR register to put the DTC into IDLE state and stop the DTC; ◆ Fill the starting address of the plug-in program into the DTCPR register; ◆ Set the INIT bit of the DTCCR register to put the DTC into POINTERCHANGE state and copy the value in the DTCPR register into the DTC; ◆ Clear the INIT bit of the DTCCR register to return the DTC to IDLE state; ◆ Set the RUN bit of the DTCCR register to put the DTC into RUNNING state and start running. The plug-in program running on the DTC performs the function of quickly shifting data from the data transfer buffer out of the I/O port, or quickly shifting data from the I/O port into the data transfer buffer. The I/O ports operated by the DTC are four JTAG signals: TCK, TMS, TDI, and TDO. TCK serves as the trigger clock for shifting in/out data; TDI serves as the output for shifting out data; TDO serves as the input for shifting in data; and TMS serves as the input signal, which, together with TCK, determines the transition process of the TAP controller state. The plug-in program is written using DTC assembly instructions, and then the assembly source code is converted into DTC machine instructions by a simple assembler provided by ST, and burned into the Flash memory of ST72651. 3.3.2 Scan Chain Operation Module The scan chain operation module calls the DTC software plug-in program to complete the initialization of the TAP controller, scan chain 1 operation, and scan chain 2 operation. (1) Initialize the TAP Controller The basic function of the TAP controller is to generate clock signals and control signals. It comprises a finite state machine with 16 states: Test-Logic-Reset, Run-Test/Idle, Select-DR-Scan, Select-IR-Scan, Capture-DR, Shift-DR, Exit1-DR, Pause-DR, Exit2-DR, Update-DR, Capture-IR, Shift-IR, Exit1-IR, Pause-IR, Exit2-IR, and Update-IR. The purpose of initializing the TAP controller is to put it into the Select-DR-Scan state. Regardless of the current state of the TAP controller, it enters the Test-Logic-Reset state whenever five TCK signals are generated when TMS is 1. Therefore, the steps to make the TAP controller enter the Select-DR-Scan state are as follows: First, set TMS to 1 to generate 5 TCK signals, so that the TAP controller enters the Test-Logic-Reset state; then set TMS to 0 to generate 1 TCK signal, so that the TAP controller enters the Run-Test/Idle state; finally, set TMS to 1 to generate 1 TCK signal, so that the TAP controller enters the Select-DR-Scan state. (2) Scan Chain 1 Operation Scan Chain 1 is a test data register in the JTAG circuit, mainly used for kernel testing and debugging. Scan Chain 1 has 33 bits, which are in the following order according to the scanning sequence: BREAKPT bit (input), D31～D0 (input/output). The purpose of the Scan Chain 1 operation is to shift in the BREAKPT bit and simultaneously shift in/out of 32 bits of data to/from the data bus. The operation steps are as follows: ◆ Initialize the TAP controller, putting it into Select-D-RScan state; ◆ Set TMS to 1, generating one TCK signal, putting the TAP controller into Select-IR-Scan state; ◆ Set TMS to 0, generating two TCK signals, putting the TAP controller into Shift-IR state; ◆ Shift the JTAG instruction SCAN_N (b0010) into the TAP controller's instruction register; ◆ Exit the Shift-IR state and enter the ShiftDR state; ◆ Shift b0001 into the scan chain selection register, selecting scan chain 1; ◆ Exit the Shift-DR state and enter the Shift-IR state; ◆ Shift the JTAG instruction INTEST (b1100) into the TAP controller's instruction register; ◆ Exit the Shift-IR state and enter the Shift-DR state; ◆ Shift in the BREAKPT bit, shifting in data D31～D0 (or shifting out data D31～D0); ◆ Make the TAP controller exit the Shift-DR state and enter the Select-DR-Scan state. (3) Scan Chain 2 Operation Scan Chain 2 is also a test data register used to access the registers of the EmbeddedICE macrocell. Scan Chain 2 has 38 bits, which are in the following order according to the scan sequence: D0~D31 of the EmbeddedICE register, A0~A4 of the EmbeddedICE register, and read/write bits. The purpose of Scan Chain 2 operation is to read and write the registers of the EmbeddedICE macrocell. The operation steps are as follows: ◆ Initialize the TAP controller, putting it into Select-DR-Scan state; ◆ Set TMS to 1, generating one TCK signal, putting the TAP controller into Select-IR-Scan state; ◆ Set TMS to 0, generating two TCK signals, putting the TAP controller into Shift-IR state; ◆ Shift the JTAG instruction SCAN_N (b0010) into the TAP controller's instruction register; ◆ Exit the Shift-IR state and enter the Shift-DR state; ◆ Shift b0010 into the scan chain selection register, selecting scan chain 2; ◆ Exit the Shift-DR state and enter the Shift-IR state; ◆ Shift the JTAG instruction INTEST (b1100) into the TAP controller's instruction register; ◆ Exit the Shift-IR state and enter the Shift-DR state; ◆ Shift in the data to be written (D0～D31); ◆ Shift in the address of the EmbeddedICE register to be read/written; ◆ Shift in the read/write bit (0 for read, 1 for write); ◆ If reading, shift out the read value D0～D31 of the EmbeddedICE register; ◆ Cause the TAP controller to exit the Shift-DR state and enter the Select-DR-Scan state. 3.3.3 EmbeddedICE Register Operation Module The reading and writing of the EmbeddedICE register is implemented through scan chain 2 operations. When reading, the address of the EmbeddedICE register to be read is used as a parameter to call the scan chain 2 operation function; when writing, the value to be written and the address of the EmbeddedICE register are used as parameters to call the scan chain 2 operation function. 3.3.4 High-level Debugging Command Module By calling the scan chain operation module and the EmbeddedICE register operation module, high-level debugging control commands such as reading and writing core registers, reading and writing memory, breakpoint and watchpoint operations, single-step or full-speed program execution are implemented. These commands are called by the main program state machine module. 3.3.5 USB Interface Driver Module The USB interface driver module mainly includes five functions: the InitUSB() function is used to initialize the USB module; the USB_Polling() function handles the USB standard device requests sent by the USB host, implements the transmission process of the USB enumeration phase, and calls the corresponding endpoint processing function according to the flag bits of the status register; the CTR (Correct Transmission) interrupt service routine is used to handle various interrupts that occur on the endpoint; the functions USB_RecvDataEP2(unsigned char *dp, uint8 len) and USB_SendDataEP2(unsigned char *dp, uint8 len) are used to receive and send USB packets from endpoint 2. 3.3.6 Main Program State Machine Module The main program state machine module cyclically calls the USB_RecvDataEP2() function of the USB interface driver module to receive command messages from the debugger. Based on the primary and secondary command numbers of the command message, it calls the corresponding command function of the higher-level debug command module and returns the data returned by the command function to the debugger via the USB_SendDataEP2() function. Finally, based on the status returned by the command function, it sends an acknowledgment message to the debugger via the USB_SendDataEP2() function. Conclusion This paper constructs an embedded system debugging tool supporting ARM cores. It first defines a lightweight remote debugging protocol, EmRDI, and then uses the ST72651 chip to implement the protocol converter EmJTAG. Currently, this debugging tool has been applied in actual embedded system development. The debugger software on the PC can download programs to the ARM-based target machine via EmJTAG and implement basic debugging functions such as setting/clearing breakpoints, setting/clearing watchpoints, and running the program at full speed/single step/stop.