As far as I understand is basic JTAG (the standard) is just a bunch of shift registers and a state machine. However the usage of JTAG to do something with a processor is not that well standardized;
What you can do is specified with the BSDL file, i mean which registers and resources you can access inside the CPU
I am afraid that a solution that works very well on one platform (ARM in this case) is not working that well on a different platform (MIPS) due to the additional logic in the JTAG interface probe
While most of modern SOCs support JTAG (IEEE 1149.1), MIPS goes for "ejtag" which is a
proprietary extension which utilizes widely used IEEE JTAG pins for debug functions in order to provide a standard debug I/O interface, enabling the use of traditional MIPS debug facilities on system-on-a-chip components with new capabilities for software and system debug.
EJTAG provides:
- run control
- single-step execution
- breakpoints on both data and instructions
- real-time trace (optional)
- direct memory access
- Debug Exception & Debug Mode (EJTAG-SPC-03-10)
- Memory-Mapped EJTAG Registers (EJTAG-SPC-03-10)
- Off-board EJTAG Memory (EJTAG-SPC-03-10)
- Debug Breakpoint Instruction (EJTAG-SPC-03-10/SDBBP)
- EJTAG Processor Core Extensions (EJTAG-SPC-03-10)
- Hardware Breakpoint Unit (EJTAG-SPC-03-10)
EJTAG utilizes a 5-pin interface defined in IEEE 1149.1. The basic Test Access Port (TAP) is composed by {TDI, TDO, TMS, TCK, nTRST}
This is the common EJTAG pinout
nTRST 1 2 GND
TDI 3 4 GND
TDO 5 6 GND
TMS 7 8 GND
TCK 9 10 GND
nSRST 11 12 -key
DINT 13 14 VCC
You can see additional pins:
* DINT pin is used to raise Debug Interrupt. Many chips has no this pin.
* nSRST pin is a "system reset" signal and acts like conventional "Reset' button (1)
(1) While nTRST is the "TAP Reset" signal, the nSRST signal does not reset TAP controller, often it resets the SoC peripherals
Debug Exception and Debug ModeTo allow inspection of the CPU state at any time in the execution flow, a debug exception with priority over all other exceptions is introduced. When a debug exception occurs, the CPU goes into
Debug Mode, a special mode with no restrictions on access to coprocessors, memory areas, etc., and where usual exceptions like address error and interrupt are masked. The
debug exception handler is executed in
Debug Mode and provided by the debug system. It can be executed from the probe through a processor access, or may also reside in the application code if the developer chooses to use a debug task in the application. An overall requirement is that debugging be non-intrusive to the application so execution of the application can be continued after the needed debug operations. However, loss of real-time operation is inevitable when the debug exception handler is executed. The system designer may chose to indicate debug mode by a signal to certain hardware modules to freeze them when executing the debug exception handler.
Memory-Mapped EJTAG RegistersEJTAG provide memory-mapped registers, located in the debug register segment (drseg), which is a sub-segment of the debug segment (dseg). They are accessible by the debug software when the processor is executing in Debug Mode. These registers provide both miscellaneous debug control and control of hardware breakpoints
Off-board EJTAG MemoryEJTAG allows a MIPS processor in Debug Mode to reference instructions or data that are not resident on the system under test. This EJTAG memory is mapped to the processor as if it were virtual memory in the kseg3 segment, and references to it are converted into transactions on the TAP interface. Both instructions and data can be accessed in EJTAG memory, which allows debugging of systems without requiring the presence of a ROM monitor or debugger scratchpad RAM. It also provides a communications channel between debug software executing on the processor and an external debugging agent.
HW specific: the EJTAG probe polls the EJTAG Control Register through the TAP, and a bit in this register indicates when a processor access is pending. The physical address of the transaction is then available in the EJTAG Address Register, and the transaction size and read/write indication are available in the EJTAG Control Register. The EJTAG Data Register is then accessed either to get data from a write or to provide data for a read. Finally the EJTAG Control Register is updated to indicate that the processor access is done.
Debug Breakpoint InstructionCPU-Specific: EJTAG introduces a new breakpoint instruction,
SDBBP, which differs from the MIPS32 and MIPS64 BREAK
Hardware BreakpointsEJTAG defines various types of hardware breakpoints for interrupting the CPU at certain transactions on the CPU buses. The debug exception happens before the bus transaction causing the exception alters any memory or CPU state. Hardware breaks on instructions have the advantage over software debug breaks in that it is possible to set them in any address area. Furthermore, if memory cannot be altered by inserting SDBBP codes, the hardware breaks can still be used. Hardware data breakpoints allow breaks on load/store operations.
EJTAG implements two kinds of breaks:
-
Instruction breaks, in which a break may be set on an instruction fetch from a specific virtual address
-
Data breaks, inwhichabreakmaybesetonaload/storereferencefromaspecificvirtualaddress,whichadditionally can be qualified by a data value.
There may be up to 15 break channels of each type implemented, and each break channel may be programmed with address, address mask, ASID, and reference type.
EJTAG Processor Core ExtensionsA MIPS processor or core supporting EJTAG must support EJTAG-specific instructions, additional system coprocessor (CP0) registers and vectoring to Debug Exceptions, which puts the processor in a special Debug Mode of execution.
Home
Help
Search
Login
Register
