2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

Dear All,
CPU:LPC2148
Compiler:WinARM
Is it really JTAG connection needed for doing embedded programming.
Right now I'm loading programs through serial port and
for trouble shooting I'm using serial port, sending SFR(required)
contents=A0on com port in ASCII format.

Ravi
[Non-text portions of this message have been removed]

=20

=20


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi Ravi

Using a serial port to send debug info is the best way to develop=20
embedded programming. I have been doing this for the last 20 years

My experience using debug tools like emulators etc was working with=20
large companies that insisted on formal testing via these tools which=20
relies on third party tools that you do not have any control over.

The more you have control, the better

Regards

Jean-Jacques
--- In l...@yahoogroups.com, "Ravi" wrote:
>
> Dear All,
> CPU:LPC2148
> Compiler:WinARM
> Is it really JTAG connection needed for doing embedded programming.
> Right now I'm loading programs through serial port and
> for trouble shooting I'm using serial port, sending SFR(required)
> contents=A0on com port in ASCII format.
>=20
> Ravi
>=20
>=20
> [Non-text portions of this message have been removed]
>

=20

=20


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Ravi schrieb:

> Is it really JTAG connection needed for doing embedded programming.

No. But as always, the right tool leads to faster results.

You are writing C or C++ not machine code, aren't you ?
--
42Bastian

Note: SPAM-only account, direct mail to bs42@...



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Ravi" wrote:
>
> Dear All,
> CPU:LPC2148
> Compiler:WinARM
> Is it really JTAG connection needed for doing embedded programming.
> Right now I'm loading programs through serial port and
> for trouble shooting I'm using serial port, sending SFR(required)
> contents on com port in ASCII format.
>
> Ravi
>

You can do embedded programming without a debugger. The serial port
method was used a lot back in the late 80's and early 90's. There are
some good debuggers that can work via the serial port, or you can just
printf to a port, but many embedded projects do not need or have
serial ports. If you can spare the JTAG pins in a project, your code
can be debugged with no code modifications and the processor load is
nil until a breakpoint is hit. There are all sorts of different tools
and levels of capabilities among tools, and the choice is yours what
to use. But if you are going to be getting paid for your time doing
embedded programming, you can make your time count for a lot more by
using the best tools that you can. ARM made EmbeddedICE available on
all their CPUs for a reason, but you do not have to use it. You do
not really need a C compiler either for that matter. ;-)

--Dave



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I finnally found someone like me heheheh
When i tell other people that i don't use a debug interface like JTAG,
they don't believe...
But i do just like you, troubleshoot using serial port...

Lucas

Ravi escreveu:
>
> Dear All,
> CPU:LPC2148
> Compiler:WinARM
> Is it really JTAG connection needed for doing embedded programming.
> Right now I'm loading programs through serial port and
> for trouble shooting I'm using serial port, sending SFR(required)
> contents on com port in ASCII format.
>
> Ravi
>
> [Non-text portions of this message have been removed]
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.17.13/1213 - Release Date: 7/1/2008 09:14
>

--
Att
Lucas Caldoncelli Rodrigues
OHM Technology
Depto. Técnico
(41) 3019-1014
(41) 8848-2255
(41) 9975-7451
www.ohmtech.com.br

Esta mensagem pode conter informação confidencial.
Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, não poderá usar, copiar ou divulgar as informações nela
contidas.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Ravi" wrote:
>
> Dear All,
> CPU:LPC2148
> Compiler:WinARM
> Is it really JTAG connection needed for doing embedded programming.
> Right now I'm loading programs through serial port and
> for trouble shooting I'm using serial port, sending SFR(required)
> contents on com port in ASCII format.
>

You may need both, depending on app. Tracing through complex data
structures without a source-level hardware debugger is a major PITA -
you usually have to keep bodging the debug and rebuilding, even if the
debug actually emerges. Most developers have better things to do :)
Most small uC have no space for complex class serialization and/or
object catalogs and other stuff that can make serial debugging/logging
easier.

I could not possibly have got my ARM app working without a hardware
debugger and other high-level tools, (Rowley).

OTOH, a hardware debugger just stops everything when it hits a
breakpoint. This is often less than useful in a real-time environment
where bugs can span threads and even machines. The JTAG debugger
cannot debug a complete system with messages flying round both inside
and between boards. Some logging of real activity is often needed to
trace the full history of a nasty bug, especially if it only occurs on
one or two particular configurations out in the field, (in winter, in
Alaska, once every two weeks on average).

It also helps, of course, if you can log on to your serial debugger
utility over networks.

Rgds,
Martin



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi Dave,=A0
"There are some good debuggers that can work via the serial port"

with regards

Ravi
On Tue, 08 Jan 2008 derbaier wrote :
>--- In l...@yahoogroups.com, "Ravi" wrote:
> >
> > Dear All,
> > CPU:LPC2148
> > Compiler:WinARM
> > Is it really JTAG connection needed for doing embedded programming.
> > Right now I'm loading programs through serial port and
> > for trouble shooting I'm using serial port, sending SFR(required)
> > contents on com port in ASCII format.
> >
> > Ravi
> >You can do embedded programming without a debugger. The serial port
>method was used a lot back in the late 80's and early 90's. There are
>some good debuggers that can work via the serial port, or you can just
>printf to a port, but many embedded projects do not need or have
>serial ports. If you can spare the JTAG pins in a project, your code
>can be debugged with no code modifications and the processor load is
>nil until a breakpoint is hit. There are all sorts of different tools
>and levels of capabilities among tools, and the choice is yours what
>to use. But if you are going to be getting paid for your time doing
>embedded programming, you can make your time count for a lot more by
>using the best tools that you can. ARM made EmbeddedICE available on
>all their CPUs for a reason, but you do not have to use it. You do
>not really need a C compiler either for that matter. ;-)
>
>--Dave
[Non-text portions of this message have been removed]

=20

=20


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "mjames_doveridge" wrote:

> OTOH, a hardware debugger just stops everything when it hits a
> breakpoint. This is often less than useful in a real-time environment
> where bugs can span threads and even machines. The JTAG debugger
> cannot debug a complete system with messages flying round both inside
> and between boards.

You are right, of course, concerning debugging with breakpoints in a
real-time system. With ARM's JTAG that should less of a problem since
the EmbeddedICE also includes ARM DCC. The DCC (Debug Communications
Channel) provides bi-directional serial communications without
stopping the processor, and since many JTAG pods can be operated via
TCP/IP there is no need to be physically present. It is usually also
much faster than a standard serial port. Where I used to work, we
sometimes( not often) did debugging from half a world away. We did use
DCC for a whole lot of serious system testing though, since it
provided a way to interact with a complex system without
significantly altering it's performance. It does require a small
amount of code to be added to the system though. OpenOCD has recently
started supporting DCC, but I have not tried that DCC implementation yet.

--Dave



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi Ravi

NO, use your imagination
write routines that sends data downg the serial port
You are in charge

Regards
--- In l...@yahoogroups.com, "Ravi" wrote:
>
> Hi Dave,=A0
> "There are some good debuggers that can work via the serial port"
>=20
> with regards
>=20
> Ravi
>=20
>=20
> On Tue, 08 Jan 2008 derbaier wrote :
> >--- In l...@yahoogroups.com, "Ravi" wrote:
> > >
> > > Dear All,
> > > CPU:LPC2148
> > > Compiler:WinARM
> > > Is it really JTAG connection needed for doing embedded=20
programming.
> > > Right now I'm loading programs through serial port and
> > > for trouble shooting I'm using serial port, sending SFR
(required)
> > > contents on com port in ASCII format.
> > >
> > > Ravi
> > >
> >
> >You can do embedded programming without a debugger. The serial port
> >method was used a lot back in the late 80's and early 90's. There=20
are
> >some good debuggers that can work via the serial port, or you can=20
just
> >printf to a port, but many embedded projects do not need or have
> >serial ports. If you can spare the JTAG pins in a project, your=20
code
> >can be debugged with no code modifications and the processor load=20
is
> >nil until a breakpoint is hit. There are all sorts of different=20
tools
> >and levels of capabilities among tools, and the choice is yours=20
what
> >to use. But if you are going to be getting paid for your time=20
doing
> >embedded programming, you can make your time count for a lot more=20
by
> >using the best tools that you can. ARM made EmbeddedICE available=20
on
> >all their CPUs for a reason, but you do not have to use it. You=20
do
> >not really need a C compiler either for that matter. ;-)
> >
> >--Dave
> >
> >
>=20
>=20
> [Non-text portions of this message have been removed]
>

=20

=20


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi Dave,
"There are some good debuggers that can work via the serial port" =A0
Could you please tell me any name for above ??

Ravi
On Tue, 08 Jan 2008 Ravi wrote :
>Hi Dave,
>"There are some good debuggers that can work via the serial port"
>
>with regards
>
>Ravi
>On Tue, 08 Jan 2008 derbaier wrote :
> >--- In l...@yahoogroups.com, "Ravi" wrote:
> > >
> > > Dear All,
> > > CPU:LPC2148
> > > Compiler:WinARM
> > > Is it really JTAG connection needed for doing embedded programming.
> > > Right now I'm loading programs through serial port and
> > > for trouble shooting I'm using serial port, sending SFR(required)
> > > contents on com port in ASCII format.
> > >
> > > Ravi
> > >
> >
> >You can do embedded programming without a debugger. The serial port
> >method was used a lot back in the late 80's and early 90's. There are
> >some good debuggers that can work via the serial port, or you can just
> >printf to a port, but many embedded projects do not need or have
> >serial ports. If you can spare the JTAG pins in a project, your code
> >can be debugged with no code modifications and the processor load is
> >nil until a breakpoint is hit. There are all sorts of different tools
> >and levels of capabilities among tools, and the choice is yours what
> >to use. But if you are going to be getting paid for your time doing
> >embedded programming, you can make your time count for a lot more by
> >using the best tools that you can. ARM made EmbeddedICE available on
> >all their CPUs for a reason, but you do not have to use it. You do
> >not really need a C compiler either for that matter. ;-)
> >
> >--Dave
> >
> >
>[Non-text portions of this message have been removed]
>
[Non-text portions of this message have been removed]

=20

=20


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Ravi" wrote:
>
> Hi Dave,
> "There are some good debuggers that can work via the serial port"
>
> with regards
>
> Ravi
>

Assuming that quote implied a question concerning what debuggers can
work that way, there is always good old GDB. There are others as
well, but none that I know of that are free like GDB. I use NoICE
which also includes serial port debugging capability. However, any
debugger that operates over the serial port is going require that it's
companion debugging stub be incorporated in your software build to
handle the debug communications. There does not seem to be very many
good reasons to work that way with ARM, since EmbeddedICE can handle
the same chores with little or no modification to the code being
debugged.

--Dave



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

>
> You are right, of course, concerning debugging with breakpoints in a
> real-time system. With ARM's JTAG that should less of a problem since
> the EmbeddedICE also includes ARM DCC. The DCC (Debug Communications
> Channel) provides bi-directional serial communications without
> stopping the processor, and since many JTAG pods can be operated via
> TCP/IP there is no need to be physically present. It is usually also
> much faster than a standard serial port. Where I used to work, we
> sometimes( not often) did debugging from half a world away. We did use
> DCC for a whole lot of serious system testing though, since it
> provided a way to interact with a complex system without
> significantly altering it's performance. It does require a small
> amount of code to be added to the system though. OpenOCD has recently
> started supporting DCC, but I have not tried that DCC implementation
yet.

I have not tried DDC in any form yet - I will look at it when my
current panic is over, (PC problem, not the ARM boards).

I cannot see how any complex system could be got working without
'blocking' *and* 'non-blocking' debuggers. The serial ports are not
much use if the app has crashed, deadlocked or livelocked in some
loop, especially if the interrupts are disabled at the time. I just
cannot imagine that I would have got my boards working at all without
a 'real' hardware debugger so I have a chance when the board will not
start at all or seizes with all interfaces deader than Hillary's
chance for the White House.

Now I have got over the low-level and overall design stuff, the debug
output streams on the boards and PCs are better for the protocol
cockups, malformed messages and other 'system-wide features' that do
not crash/block any subsystem/board, but still screw up the system as
a whole.

Rgds,
Martin



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "jdauchot" wrote:
>
> Hi Ravi
>
> NO, use your imagination
> write routines that sends data downg the serial port
> You are in charge
>
> Regards
>

Well, everyone to their own, I suppose. The best adjective I can
think of for your approach is 'brave'...

I have not been in charge of software since 'Hello World'. It is
evil, malicious, nasty and will do anything in its power to drive you
insane. It has to be hammered into working using every tool you can
get your hands on, and then tested extensively to curb its instinct to
fight back and escape its specification through any wormhole it can find.

Then there's the hardware...

Rgds,
Martin



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

At 08:01 PM 1/8/2008 +0000, mjames_doveridge wrote:
>--- In l...@yahoogroups.com, "jdauchot" wrote:
> >
> > Hi Ravi
> >
> > NO, use your imagination
> > write routines that sends data downg the serial port
> > You are in charge
> >
> > Regards
> >Well, everyone to their own, I suppose. The best adjective I can
>think of for your approach is 'brave'...

I had thought that approach was fairly standard. I've done a fair amount
of work where I would consider using an ICE (or even worse JTAG) dangerous
due to their intrusive nature. Serial port or similar with some logging
was the only safe and practical way to accomplish the task.

In my experience 95+% of software testing and debugging is
straightforwardly accomplished with a serial port, logic analyzer and
oscilloscope and a little thinking. Adding JTAG can accomplish 50-90% of
the remaining. The remaining may require a real ICE.

In my darker moments I sometimes think JTAG debugging is being used in
place of thought.

Robert

http://www.aeolusdevelopment.com/

From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "derbaier" wrote:
>
> --- In l...@yahoogroups.com, "Ravi" wrote:

> > "There are some good debuggers that can work via the serial port"

> There does not seem to be very many
> good reasons to work that way with ARM, since EmbeddedICE can handle
> the same chores with little or no modification to the code being
> debugged.

The Angel monitor was an on-chip program that directly interfaced to
EmbeddedICE and surfaced the RDI debugging API to the PC over a serial
port. I know that Atmel embraced it, but I don't think Philips ever did.

It has mostly died out because it was very slow. JTAG emulators
provide a much faster interface.

Eric



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, Robert Adsett I've done a fair >amountof work where I would consider using an ICE
> (or even worse JTAG) dangerous due to their intrusive nature.

OK, it is fairly easy to understand why you find ICE intrusive since
it substitutes the system processor with it's own, and often also uses
it's own memory system that in recent years constrains system clock
speeds to less than the design speed of the final product. But how
does JTAG come out to be "even worse" when it uses the ALL the end
product system resources exactly as they will be in the final product,
and has no effect on system performance until a breakpoint is reached?
With ARM's JTAG DCC, breakpoint debugging is a convenience, but not
a necessity, so the level of system intrusion is purely a matter of
choice by the developer. Since JTAG is also used for boundary scan
testing, and can do the code loading for all devices on a single PC
board, it's utility pretty much speaks for itself?

> Serial port or similar with some logging was the only safe and
> practical way to accomplish the task.

Actually ARM's JTAG DCC does that without consuming any system
resources other than the pins necessary for JTAG anyway. In most
complex products JTAG needs to be there anyway to do the normal
production boundary scan testing, so the pins are already there.
>
> In my experience 95+% of software testing and debugging is
> straightforwardly accomplished with a serial port, logic analyzer and
> oscilloscope and a little thinking.

Thinking is always of primary importance, and the logic analyzer
and oscilloscope can be very useful in analyzing intersystem
comunications problems, along with protocol analyzers, and spectrum
analyzers in RF systems. Those special function tools are all
good adjutants to the debugging tool set. However, adding an
unnecessary serial port to a product just for debugging could
be considered a resource waste when there are better ways like
JTAG DCC in ARM products.
> Adding JTAG can accomplish 50-90% of
> the remaining. The remaining may require a real ICE.

The major advantage a "real ICE" has over JTAG in software development
is in software profiling. Now that ARM has Embedded Trace that
advantage is pretty much lost. What other advantage does ICE have?

>
> In my darker moments I sometimes think JTAG debugging is being used in
> place of thought.
>

Critical thinking is the most valuable tool in any developer's
toolkit, but it seems pretty prejudicial to claim that any of
the other tools are replacing it.

--Dave



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "derbaier" wrote:
>
> --- In l...@yahoogroups.com, "Ravi" wrote:

> > "There are some good debuggers that can work via the serial port"

> There does not seem to be very many
> good reasons to work that way with ARM, since EmbeddedICE can handle
> the same chores with little or no modification to the code being
> debugged.

Personally, I have seen the availability of a fast JTAG interface as an
important part of the equation when people consider a move from the 8-bit
devices to LPC2xxx (and similar chips).

Michael.
Michael.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> I had thought that approach was fairly standard. I've done a fair
amount
> of work where I would consider using an ICE (or even worse JTAG)
dangerous
> due to their intrusive nature. Serial port or similar with some
logging
> was the only safe and practical way to accomplish the task.

Well, I can agree that it is used, and I would certainly agree that
the most complex controller board should still have a serial port and
simple human interface somewhere. Such serial interfaces will often
still work when nothing else does & so give the poor service engineer
a chance to work out what's going on in some freezing portakabin in
the middle of nowhere. Also, of course, it allows simple, local board
logging to a laptop, so allowing problems to be trapped even if
intermittent.

OTOH, the idea that a serial port can be used *on its own* to develop
any size and complexity of system hardware and software seems to me to
be a bit surreal.

It's for sure that a real ICE, with its adaptor box, headers, cables
etc. are physically intrusive. In a tightly-packed rack, there is not
enough space to get the ICE in without an extender card, and once the
extender is in, the timings change on the bus :(

That card would, presumably. never have been placed in the rack in the
first place if it did not work at all. The fact that it works a bit
is due to some hardware/software engineers with hardware debuggers who
found and fixed the track errors, pin misdefines, bad addressing, chip
errata etc that stopped the first versions of the board working at all.

A serial port only needs a couple wires and surely cannot be described
as intrusive hardware-wise. It is intrusive software-wise: it needs
an interrupt, buffers etc. and so consumes some resources. I am
always willing to pay that price if I can - if a serial interface is
overstretching the board, the thing is seriously close to overload anyway.

> In my experience 95+% of software testing and debugging is
> straightforwardly accomplished with a serial port, logic analyzer and
> oscilloscope and a little thinking. Adding JTAG can accomplish
50-90% of
> the remaining. The remaining may require a real ICE.

Some posters seem to imply that a serial port can replace all the
complex and useful hardware/software tools that you list above. If
the board is stone dead, I need a meter first to check the power, not
a 9-pin<>header lead that may, or may not, be wired correctly anyway.

> In my darker moments I sometimes think JTAG debugging is being used in
> place of thought.
>

Maybee you need better illumination above your lab bench

Actually, I have to confess that I have used JTAG and a real board in
just that way on occasions. One that comes to mind is the messy GAF
in the CAN interfaces. The structure of the GAF has four indexes and
new data has to be inserted in ascending order with all data above
moved up to make room. Furthermore, the CAN has to be shut down first
before the GAF can be edited and this means that all buffers in tx
queues etc. have to be purged and the interrupts all confirmed over
and buffers repooled.

The software to do this hurt my head a lot and I resorted to tracing
it through, almost developing it, with the debugger. Sorting that
with a serial interface would have caused serious mental illness.

Rgds,
Martin



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "mjames_doveridge" wrote:
>
> Well, I can agree that it is used, and I would certainly agree that
> the most complex controller board should still have a serial port and
> simple human interface somewhere. Such serial interfaces will often
> still work when nothing else does & so give the poor service engineer
> a chance to work out what's going on in some freezing portakabin in
> the middle of nowhere. Also, of course, it allows simple, local board
> logging to a laptop, so allowing problems to be trapped even if
> intermittent.
>
> OTOH, the idea that a serial port can be used *on its own* to develop
> any size and complexity of system hardware and software seems to me to
> be a bit surreal.
>

It is apparent that people are coming at this question from a lot of
different angles, so here is why I have the views that I have. BTW, I
can see your point about the usefulness of a serial port in the
situations you describe. Ever since I started working with ARM
processors about 10 years ago, they have been deeply embedded in ASICs
containing hundreds of other functions. In the beginning of that time
period ICE was still used for development work, but it required that
the ASIC be designed to accomodate the ICE, and that was a significant
compromise in the ASIC's hardware design. It required reversing signal
direction on some pins, and significantly altered the timing on most
all affected pins. JTAG was a major improvement over the ICE since it
allowed the ASIC to be designed without ICE specific compromises, and
JTAG was necessary for ASIC boundary scan testing anyway. That made
JTAG debug access practically free, and as a side benefit,we no longer
needed to tolerate the agonizingly slow code download of many
megabytes of code via a UART serial port. Logging and other complex
performance testing could also be easily conducted using ARM's DCC
over the JTAG interface as well. For these types of applications
UARTs are simply not needed, or even available, anymore. Now that I am
out of that particular rat race, I still do my own development
projects using similar techniques that worked so well then.

--Dave



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

At 07:04 AM 1/9/2008 +0000, derbaier wrote:
>--- In l...@yahoogroups.com, Robert Adsett
> >
> > I've done a fair >amountof work where I would consider using an ICE
> > (or even worse JTAG) dangerous due to their intrusive nature.
>
>OK, it is fairly easy to understand why you find ICE intrusive since
>it substitutes the system processor with it's own, and often also uses
>it's own memory system that in recent years constrains system clock
>speeds to less than the design speed of the final product. But how
>does JTAG come out to be "even worse" when it uses the ALL the end
>product system resources exactly as they will be in the final product,
>and has no effect on system performance until a breakpoint is reached?

It stops the processor in order to do anything. It doesn't get much more
intrusive than that. Since ICEs have dual port memory it is quite possible
to observe and sometimes even change values on a running system. With JTAG
that's not possible.

Now consider a system where stopping the CPU can result in a short across a
high power bus. JTAG is not on.

>With ARM's JTAG DCC,

A serial port by any other name...

There is still an advantage to a real serial port if for no other reason
than to be able to get access w/o specialty hardware.

>breakpoint debugging is a convenience, but not
>a necessity, so the level of system intrusion is purely a matter of
>choice by the developer. Since JTAG is also used for boundary scan
>testing, and can do the code loading for all devices on a single PC
>board, it's utility pretty much speaks for itself?

I didn't say it wasn't useful, just that a serial port covers a lot of the
necessary bases. Although I have debugged startup code with just a serial
port and an oscilloscope it is rather nice to have JTAG to work with. When
working at the application level I find the serial port just as useful and
fast.

> > Serial port or similar with some logging was the only safe and
> > practical way to accomplish the task.
>
>Actually ARM's JTAG DCC does that without consuming any system
>resources other than the pins necessary for JTAG anyway. In most
>complex products JTAG needs to be there anyway to do the normal
>production boundary scan testing, so the pins are already there.

You apparently use more complex chips than I do. Typically the only IC on
board with JTAG on a system I've built is the micro. The pins taken by
JTAG may only be more useful for system use though.

> >
> > In my experience 95+% of software testing and debugging is
> > straightforwardly accomplished with a serial port, logic analyzer and
> > oscilloscope and a little thinking.
>
>Thinking is always of primary importance, and the logic analyzer
>and oscilloscope can be very useful in analyzing intersystem
>comunications problems, along with protocol analyzers, and spectrum
>analyzers in RF systems. Those special function tools are all
>good adjutants to the debugging tool set.

An oscilloscope is not a special function adjutant. It a necessity for
serious embedded work. How else would you find out that under certain
circumstance the timers on the LPCs can emit nS wide pulses (and they can)
or verify the width of sub mS pulses? A logic analyzer is very nice but
not as essential as on oscilloscope.

>However, adding an
>unnecessary serial port to a product just for debugging could
>be considered a resource waste when there are better ways like
>JTAG DCC in ARM products.

A serial port is still the most widely available interface for hooking up
to a system. It is almost never a waste.

> > Adding JTAG can accomplish 50-90% of
> > the remaining. The remaining may require a real ICE.
>
>The major advantage a "real ICE" has over JTAG in software development
>is in software profiling. Now that ARM has Embedded Trace that
>advantage is pretty much lost. What other advantage does ICE have?

Trace does take up a fairly large number of additional pins. Complaining
about ETM cost when you then compare it to an ICE seems sort of silly :)

Besides trace an ICE often gives the ability to modify memory on the fly.

More importantly it allows a wider range of breakpoints and especially
watchpoints. The obvious things missing from JTAG are traps on writes to
read only memory and sophisticated memory breakpoints such as
break if address range XXXX is accessed when code is not in range YYYY
An ICE can have these. You don't need them often but when you do.....

Some of these can probably be provided by a trace (although maybe not with
instruction level precision) but I've not seen that they all can. That may
be just because I haven't looked hard enough.

The real advantage of JTAG is cost. Compared to the $10K+ of a decent ICE,
JTAG is free. That and performance issues with high end micro speeds have
essentially driven the ICE into oblivion.
> >
> > In my darker moments I sometimes think JTAG debugging is being used in
> > place of thought.
> >Critical thinking is the most valuable tool in any developer's
>toolkit, but it seems pretty prejudicial to claim that any of
>the other tools are replacing it.
As I said it's in my darker moments. I have, however, seen the effects of
people bulling ahead with JTAG and not stopping and thinking. It's amazing
how effective a lab book recording what happens as you change things can be
as an aid to finding problems.

Robert

http://www.aeolusdevelopment.com/

From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

At 08:23 AM 1/9/2008 +0000, mjames_doveridge wrote:
> > I had thought that approach was fairly standard. I've done a fair
>amount
> > of work where I would consider using an ICE (or even worse JTAG)
>dangerous
> > due to their intrusive nature. Serial port or similar with some
>logging
> > was the only safe and practical way to accomplish the task.
>
>Well, I can agree that it is used, and I would certainly agree that
>the most complex controller board should still have a serial port and
>simple human interface somewhere. Such serial interfaces will often
>still work when nothing else does & so give the poor service engineer
>a chance to work out what's going on in some freezing portakabin in
>the middle of nowhere. Also, of course, it allows simple, local board
>logging to a laptop, so allowing problems to be trapped even if
>intermittent.

Indeed

>OTOH, the idea that a serial port can be used *on its own* to develop
>any size and complexity of system hardware and software seems to me to
>be a bit surreal.

You'll have to define 'any size and complexity' ;)
>It's for sure that a real ICE, with its adaptor box, headers, cables
>etc. are physically intrusive. In a tightly-packed rack, there is not
>enough space to get the ICE in without an extender card, and once the
>extender is in, the timings change on the bus :(

I'm more worried about the fire ;)

Seriously though I don't mean to imply JTAG is neither useful nor
desirable. A good JTAG interface is a good thing. I'm just emphasizing
that much can be accomplished with a serial port, some of them items that
cannot be done with JTAG (perhaps even with DCC).

>A serial port only needs a couple wires and surely cannot be described
>as intrusive hardware-wise. It is intrusive software-wise: it needs
>an interrupt, buffers etc. and so consumes some resources. I am
>always willing to pay that price if I can - if a serial interface is
>overstretching the board, the thing is seriously close to overload anyway.

The serial port normally doesn't stop the processor as JTAG does. An
important point on occasion.

>
> > In my experience 95+% of software testing and debugging is
> > straightforwardly accomplished with a serial port, logic analyzer and
> > oscilloscope and a little thinking. Adding JTAG can accomplish
>50-90% of
> > the remaining. The remaining may require a real ICE.
>
>Some posters seem to imply that a serial port can replace all the
>complex and useful hardware/software tools that you list above. If
>the board is stone dead, I need a meter first to check the power, not
>a 9-pin<>header lead that may, or may not, be wired correctly anyway.

I wouldn't want to try to work on any but the slowest embedded systems
without an oscilloscope. Even then I'd feel handicapped.

>
> > In my darker moments I sometimes think JTAG debugging is being used in
> > place of thought.
> >Maybee you need better illumination above your lab bench

100kW Halogen maybe :)
>Actually, I have to confess that I have used JTAG and a real board in
>just that way on occasions.

I have as well. More than once I've caught myself on the third revision
and realized I needed to go back a few steps and approach the problem again
in the systematic fashion I should have started with.

Robert

"C is known as a language that gives you enough rope to shoot yourself in
the foot." -- David Brown in comp.arch.embedded
http://www.aeolusdevelopment.com/



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, Robert Adsett wrote:
Thank you for your very well thought out reply, Robert. We obviously
have worked on very different systems that have shaped our opinions on
this subject. When trying to see things from your viewpoint, your
opinion makes a lot of sense from that point of view. From my point of
view, I can not agree with all your assessments, but I will not
belabor them either, except for one little point. I would like to
take exception to your view that JTAG EmbeddedICE based systems are
excessively obtrusive. Breakpoint debugging is obtrusive with any
debug system, whether serial, ICE, or EmbeddedICE, so calling JTAG
EmbeddedICE intrusive for that reason does not work, IMHO. While it is
true that an ICE can alter system variables on the fly, it does so at
significant expense to system performance on systems running much
faster than the old 8 bit processors. EmbeddedICE's DCC can also
modify system variables on the fly, but the performance hit only
occurs as the variable is modified or read. ICE is always very
intrusive because of it's effect on system performance, while the
EmbeddICE has absolutely no effect on system performance unless ARM is
halted in debug mode. But, a serial port debugger or ICE would also
have a similar effect if a breakpoint is hit. Using DCC with ARM's
JTAG EmbeddedICE loads system resources less than than UART support
does (IMHO), but you are absolutely correct that it is in essence just
another serial port.

My experience with using the DCC( Debug Communications Channel) of
ARM's EmbeddedICE has been with Lauterbach's Trace32 debugger at my
former employer, but now that OpenOCD has added DCC support I am
itching for an excuse to give it a try! :-)
So far, I have not tried it, but I would really like to hear if anyone
else has?

--Dave



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Robert,

> >OK, it is fairly easy to understand why you find ICE intrusive since
> >it substitutes the system processor with it's own, and often also uses
> >it's own memory system that in recent years constrains system clock
> >speeds to less than the design speed of the final product. But how
> >does JTAG come out to be "even worse" when it uses the ALL the end
> >product system resources exactly as they will be in the final product,
> >and has no effect on system performance until a breakpoint is reached?
>
> It stops the processor in order to do anything. It doesn't get much
> more intrusive than that. Since ICEs have dual port memory it is quite
> possible to observe and sometimes even change values on a running system.
With
> JTAG that's not possible.

On ADIv5 that isn't true--Cortex processors do not always need to be
stopped.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Paul Curtis" wrote:
>
> Robert,
>
> > >OK, it is fairly easy to understand why you find ICE intrusive since
> > >it substitutes the system processor with it's own, and often also
uses
> > >it's own memory system that in recent years constrains system clock
> > >speeds to less than the design speed of the final product. But how
> > >does JTAG come out to be "even worse" when it uses the ALL the end
> > >product system resources exactly as they will be in the final
product,
> > >and has no effect on system performance until a breakpoint is
reached?
> >
> > It stops the processor in order to do anything. It doesn't get much
> > more intrusive than that. Since ICEs have dual port memory it is
quite
> > possible to observe and sometimes even change values on a running
system.
> With
> > JTAG that's not possible.
>
> On ADIv5 that isn't true--Cortex processors do not always need to be
> stopped.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>

Thanks for that reference, Paul. That sent me off to ARM's site to
read more about the ADIv5 DAP. As usual, I am behind the times again.
That looks like a great enhancement to ARM's already good debug
capabilities.

--Dave



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

derbaier Wrote
>--- In l...@yahoogroups.com, Robert Adsett wrote:
>
>Thank you for your very well thought out reply, Robert. We obviously
>have worked on very different systems that have shaped our opinions on
>this subject. When trying to see things from your viewpoint, your
>opinion makes a lot of sense from that point of view. From my point of
>view, I can not agree with all your assessments, but I will not
>belabor them either, except for one little point. I would like to
>take exception to your view that JTAG EmbeddedICE based systems are
>excessively obtrusive. Breakpoint debugging is obtrusive with any
>debug system, whether serial, ICE, or EmbeddedICE, so calling JTAG
>EmbeddedICE intrusive for that reason does not work, IMHO.=20

True, but I didn't say anything about breakpoints. That's why I refer to
JTAG as more intrusive than either an ICE or a serial port. You have to
stop the micro to get information out. That's often (maybe even usually)
not true of an ICE, it's definitely not true of a serial port.

>While it is
>true that an ICE can alter system variables on the fly, it does so at
>significant expense to system performance on systems running much
>faster than the old 8 bit processors. EmbeddedICE's DCC can also
>modify system variables on the fly, but the performance hit only
>occurs as the variable is modified or read.=20

Hmm, I thought it just provided a serial communications channel and any
memory manipulation would have to be done in a user supplied code fragment.

> ICE is always very
>intrusive because of it's effect on system performance,=20

Depends on how fast the system is of course. I've used it on 20MHz 16 bit
systems with no performance hit (the soldered tower replacing the micro was
another matter ;)). I expect a similar device for one of the LPCs wouldn't
fare nearly so well though.

> while the
>EmbeddICE has absolutely no effect on system performance unless ARM is
>halted in debug mode. But, a serial port debugger or ICE would also
>have a similar effect if a breakpoint is hit. Using DCC with ARM's
>JTAG EmbeddedICE loads system resources less than than UART support
>does (IMHO), but you are absolutely correct that it is in essence just
>another serial port.=20

Serial port overhead is pretty low. Just a few buffers and an interrupt
routine to send the bytes out. Depending on how it's being used the
overhead on the CPU can often be zero. And I feel a lot more confident of
hooking up a serial cable to a running system than a JTAG cable.

I'm not saying that a serial port can do all that JTAG can, but neither can
JTAG do all that a serial port can.

Robert
--------------------------------------------------------------------
mail2web.com - Microsoft=AE Exchange solutions from a leading provider -
http://link.mail2web.com/Business/Exchange

=20

=20


(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "subscriptions@..."
wrote:

> True, but I didn't say anything about breakpoints. That's why I
refer to
> JTAG as more intrusive than either an ICE or a serial port. You have to
> stop the micro to get information out. That's often (maybe even
usually)
> not true of an ICE, it's definitely not true of a serial port.

Of course that all depends on how you use the ICE, and whether you
have a debugger or just a logger on the serial port. Breakpoints are
breakpoints no matter what system is using them. Breakpoint debugging
is not a necessity with any of the three in question here.

>

>
> Hmm, I thought it just provided a serial communications channel and any
> memory manipulation would have to be done in a user supplied code
fragment.

Apparently you are refering to DCC? Of course user supplied code
fragments are necessary, since it is basically just a very high speed,
low overhead, and cost free serial port as I said in my post.

>
> > ICE is always very
> >intrusive because of it's effect on system performance,
>
> Depends on how fast the system is of course. I've used it on 20MHz
16 bit
> systems with no performance hit (the soldered tower replacing the
micro was
> another matter ;)). I expect a similar device for one of the LPCs
wouldn't
> fare nearly so well though.

I have used a Lauterbach ICE with ARM's running at 27MHz, but that was
just about the limit before we had to give them up. Even at that
speed it was not always very reliable, and since it was with full
custom ASICs that had a deeply embedded ARM processor, it seriously
complicated the ASIC design. It also made it impossible to use the ICE
in the final product, but by switching over to JTAG that limitation
also went away.

> Serial port overhead is pretty low. Just a few buffers and an interrupt
> routine to send the bytes out. Depending on how it's being used the
> overhead on the CPU can often be zero. And I feel a lot more
confident of
> hooking up a serial cable to a running system than a JTAG cable.

OK, confidence in a method is a personal choice, and I can not argue
with that.

>
> I'm not saying that a serial port can do all that JTAG can, but
neither can
> JTAG do all that a serial port can.
>
There are not many high volume ARM applications left today that
include serial ports. ARM is in PDAs, MP3 players, cell phones, smart
phones, palm top computers, navigation sytems, automobile engine
suspension and braking systems, and many other high volume
aplications. Few( maybe none now?) of them have UARTs or serial ports.
However, they all still debuggable via JTAG with EmbeddedICE and it's
sucessors, with greater efficiency and speed. If the luxury of an old
style serial port is available in a product, then it is at least an
option that one can use. However, I do not think that people new to
this business should be encouraged to develop a debugging style that
can not be supported by modern ARM applications.

I suppose most people are tired of this subject now, so I will give it
a rest.

--Dave



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

>Using a serial port to send debug info is the best way to develop
>embedded programming. I have been doing this for the last 20 years

I am also using the same and never felt the need in last 15 years.

And when serial port is also not available use LED.
Warm Regards,

Mukund Deshmukh,
Beta Computronics Pvt Ltd.
10/1 IT Park, Parsodi,
Nagpur -440022 India.
Web site - http://betacomp.com

MEET US AT,

Chinaplas 2008, Shanghai, China.



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )