On Wed, 2012-04-11 at 23:13 +0800, lobachevsky wrote:
> hi, all,
>
> I am writing this letter to ask some questions about debug interface.
>
> Usually, we use JTAG as the debug interface, which is used to connect
> between host and target embedded MCU (SoC). So host communicate with
> SoC through JTAG. So:
Hi lobachevsky,
JTAG is the physical interface for communicating with the debug
sub-system on chip. It is IEEE standard 1149.1, and there is a good
summary article on Wikipedia
http://en.wikipedia.org/wiki/Jtag
Essentially JTAG allows you to shift registers in and out of a chip. The
OpenRISC debug systems (there is more than one to choose from),
essentially use this mechanism to allow you to do three things.
- read and write from addresses on the WishBone bus.
- read and write special purpose registers (SPRs).
- reset, stall and unstall the CPU.
In particular, depending on the debug controller, by writing SPRs, you
may be able to set up hardware breakpoints and watchpoints, request the
processor to stall on certain exceptions and so forth.
> 1. When download firmware to SoC, host send a 'command' to SoC's debug
> controller to tell SoC to hold the reset, and firmware is transmit
> from host to target SoC. Is my understanding above correct?
Broadly. Stall the processor, load the memory, reset the processor.
> 2. The physical layer protocol of the communication is determined by
> JTAG. How about the 'command' (data link layer) protocol? Who defines
> the protocol? And where can I find the protocol?
The ISO levels don't really map very well, but the interface to the
debug unit is described in the OpenRISC design documents. There is the
low level JTAG mechanism, known as the Test Access Port (TAP) and there
is the debug controller protocol. You should find the documents in the
separate TAP and Debug Interface projects on SVN.
> 3. If host wanna set a hardwire break point, host set transfer the
> break point PC value to target SoC. SoC's debug controller receives
> the PC value and saves it at some place, probably a register. Then the
> MCU is running. Debug controller check if current PC value is equal to
> the value restored in the break point register. If equals, then stop
> the MCU. Is my understanding correct?
Various ways. The Mohor debug controller implements hardware
breakpoints, which are set through SPRs. The SPRs can also be set to
stall the processor on hitting such a breakpoint. The host debugger will
poll using JTAG until it sees the processor stalled, when it can
interrogate the SPRs to find out about the breakpoint.
But you can also implement software breakpoints using the l.trap
instruction. This is essential if you need more than a small number of
breakpoints.
> 4. If all the break point information is transmit from host to target
> through JTAG, then the data link layer protocol is predefined by
> someone? Which may be the same as question No. 2?
It is.
> 5. If the break point register save the PC value, then then hardwire
> break point number is limited, which is limited by the register
> number. Is my understanding correct?
You are correct - true of all architectures implementing hardware
breakpoint. In the case of the Mohor debug controller a maximum of eight
hardware breakpoints may be set
> 6. How about watch point? How does a CPU realize a hardwire watch
> point?
Depends on the debug controller. In the case of the Mohor controller the
SPRs are shared with the hardware breakpoints, and a watchpoint
typically needs two registers.
> 7. Is there a book or manual to describe the above things clearly?
Loads of general stuff on the Internet. The OpenRISC documents are in
SVN for the individual projects.
HTH,
Jeremy
--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: [email protected]
Web: www.embecosm.com
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc
