However i am getting slightly confused at the different options for
debuging. Am i right in thinking (after kindly being pointed in the
right direction) that:
a) Angel is a monitor program, which talks over the serial port.
b) RedBoot is a different kind of monitor program, which again talks
over the serial port.
I have seen JTAG interfaces, in order to debug the software with JTAG
do i need to run a monitor program, or is it all done in hardware? Can
i download program code with JTAG on the arm?
TIA,
Chris
> a) Angel is a monitor program, which talks over the serial port.
Correct. The protocol it talks is called ADP (Angel Debug
Protocol, IIRC). The GDB "rdi" target code impliments the ADP
protocol via serial, serial/parallel, or Ethernet (UDP). Angel
doesn't handle high baud rates, and is reportedly rather fragile.
> b) RedBoot is a different kind of monitor program, which again talks
> over the serial port.
Correct. RedBoot talks the GDB "remote" protocol (which is
implimented by the GDB "remote" target. RedBoot will talk via
serial or via Ethernet (TCP/IP). It's open-source and ported
to a number of ARM eval boards.
> I have seen JTAG interfaces, in order to debug the software
> with JTAG do i need to run a monitor program, or is it all done
> in hardware?
There's a hardware debug macrocell in the processor that
handles everything. No software required on the ARM.
> Can i download program code with JTAG on the arm?
Yes.
To use JTAG you'll need an interface box. These range from a
few hundred USD to a few thousand USD. The higher end ones
talk Ethernet and include processors to handle all of the
low-level JTAG stuff. The low end ones are essentially line
driver/receivers for the IMB-PC parallel port and the host has
to do bit-banging shift-register-in-SW. As you can imagine,
downloading via Ethernet is several orders of magnitude faster
than downloading via parallel-port-bit-banger.
The intelligent JTAG boxes impliment some sort of protocol
between themselves and the host containing the debugger. These
include:
1) ADP
EPI Jeeni (serial or Ethernet)
ARM EmbeddedICE (serial/parallel)
2) GDB "remote"
Abatron 2000 (Ethernet)
3) Proprietary
Most everthing else...
To use a box in category 3, you either have to have a debugger
that understands the proprietary protocol or run a server
daemon the translates between the proprietary protocol and
something the debugger understands. This latter approach is
used with GDB and the Jeeni Majic and the ARM MultiICE.
Clear as mud?
--
Grant Edwards grante Yow! These PRESERVES
at should be FORCE-FED to
visi.com PENTAGON OFFICIALS!!
No
> or is it all done in hardware?
Yes
> Can i download program code with JTAG on the arm?
Yes
The main disadvantage of JTAG over a monitor is that JTAG stops the processor
dead whilst you're debugging. Interrupts won't be serviced and threads/tasks
can't be scheduled. The clock stops.
Mike.
--
Michael Williams Tel: +44 1223 400458
Senior Engineer Web: http://www.arm.com/
Development Systems, ARM Limited, 110 Fulbourn Road, Cambridge, CB1 9NJ, UK
>The main disadvantage of JTAG over a monitor is that JTAG stops the processor
>dead whilst you're debugging. Interrupts won't be serviced and threads/tasks
>can't be scheduled. The clock stops.
Disadvantage? That's a major advantage! It's not so nice when you
watchdog causes a reset just because you've hit a breakpoint and need
a few milliseconds to think.
YMMV.
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Web: www.denx.de
Unix: Some say the learning curve is steep, but you only have to
climb it once. - Karl Lehenbauer
>Michael Williams <michael....@arm.com> writes:
>
>>The main disadvantage of JTAG over a monitor is that JTAG stops the processor
>>dead whilst you're debugging. Interrupts won't be serviced and threads/tasks
>>can't be scheduled. The clock stops.
>
>Disadvantage? That's a major advantage! It's not so nice when you
>watchdog causes a reset just because you've hit a breakpoint and need
>a few milliseconds to think.
>
>YMMV.
>
>Wolfgang Denk
I see this as a disadvantage too!. How can you debug a realtime system
with slowing down or stopping the processor ?
How can you track realtime behavior with stopping a CPU, not many
tools can do this! To my knowledge only a logic analyzer can capture
realtime data and analyze this afterwards.
-b
...or an ARM Trace solution, using ARM ETM (Embedded Trace Macrocell).
-p
--
Paul Gotch Trace, Profiling and Analysis Group ARM LTD.
Any views or opinions contained in this post are not necessarily
shared by my employer.
---------------------------------------------------------------------
While I agree with this in general, some systems will physically break if
stopping everything. And for other systems the debug session is just not
very fruitfuil if stopping execution.
For those, it is better with a monitor (or possibly a system with both).
This would allow to debug low priority threads while high priority
interrrupts are executing as normal.
However, with ARM, a monitor can be used also with JTAG since ARM allows for
serial communication with a serial port in the ARM core using JTAG. This is
called the Debug Comms Channell, or DCC. (Available on newer cores.)
/sten
---
For direct email, remove _ and X
>>>The main disadvantage of JTAG over a monitor is that JTAG stops the processor
>>>dead whilst you're debugging. Interrupts won't be serviced and threads/tasks
>>>can't be scheduled. The clock stops.
...
>>Disadvantage? That's a major advantage! It's not so nice when you
>>watchdog causes a reset just because you've hit a breakpoint and need
>>a few milliseconds to think.
...
>I see this as a disadvantage too!. How can you debug a realtime system
>with slowing down or stopping the processor ?
First let's make clear that you introduce the term "realtime system"
here; it was not mentioned before in this discussion.
Second, all too often your only chance to _debug_ a realtime system
is to be able to freeze the whole system under certain conditions,
for example to inspect the state of several related tasks in a
certain situation. It does not help you much if you stop one task in
a breakpoint while interrupt handlers and other tasks continue to
change the system state, or if timers expire while you are sitting in
a breakpoint.
Of course there are also situations where you only want to stop a
specific task, but this is a different story, and usually possible by
any standard debugger - not the type of problem you would address
with a JTAG box.
>How can you track realtime behavior with stopping a CPU, not many
>tools can do this! To my knowledge only a logic analyzer can capture
>realtime data and analyze this afterwards.
You are probably referring to execution traces etc. here. This is a
different issue. Normally "debugging" means the activity you perform
using a debugger, i. e. for example settin breakpoints, single
stepping, watching data and system state, etc.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Web: www.denx.de
Machines take me by surprise with great frequency. - Alan Turing
That's where a simulator for the whole system (including devices &
interrupt handlers etc) can come in very handy. Stop system, look at
all tasks, and let it go again.
See http://www.virtutech.com/simics/mascots2k-debugger.pdf for more on
realtime debugging in simulation.
/jakob
"Jakob Engblom" <ja...@virtutech.com> wrote in message
news:80c81770.02112...@posting.google.com...