how JTAG debugger halts the core of ARM based device?

Question

I am trying to understand the process that happens behind JTAG debugging. From what i understood, devices that supports JTAG debugging has a special component in the device that is called DOC(Debug On Chip). The core of this component is TAP controller that responsible to perform requests from the connected JTAG adapter.

can somebody please explain what happens in the moment that the adapter sends halting request to TAP controller? I am not interested in details about electrical signals but more about the process. Does any register of the DOC has to be set in order to halt the system? if so how the DOC "knows" when to check the value of this register?

I also know that on most of the ARM processors the DOC can't access cores registers unless it is halted. but does any kernel process can access to the registers of the DOC?

thank you!

Answer 1

The arm documentation describes the debug tap controller, the jtag accessible registers, the sequence of register writes and reads required to perform a halt or any other command from jtag.

http://infocenter.arm.com

There are two basic approaches

1) JTAG wasn't invented to be a software debugging platform it was for chip and board testing. Even though it was already there for chip and board testing, you might as well also use it for software debugging. The very ugly but functional thing you can do is use jtag to take over bits in the chip, the boundary scan for example and single step the processor by controlling the clock input. You can also take over external busses like the boot flash, etc. - ugly but functional.

2) You develop the processor with JTAG-based debugging in mind, so the pipeline to the core has this debugging fully integrated in some form or fashion (which is dependent on the processor vendor and product line and perhaps each individual design engineer does their own thing). You are basically sending commands or talking to registers in the debugger via your JTAG interface, and these registers control the processor in whatever way the designer allows.

Now for benefits, ARM or mips or Intel or whomever will not re-design their ocd every time. If they changed it every time then all the tool vendors would have to invest NRE into supporting a new thing, and eventually or from time to time they would look at your product or the market and decide they are not going to support that new chip/design. If the same on-chip debugger or the same baseline design with perhaps a new optional feature every so often is used, then the tools vendors don't have to change anything or perhaps only have to add another JTAG ID to their list of known processor types, and the rest of their code won't have to change.