Lpc2000

At 07:12 AM 12/18/05 -0500, Tom Walsh wrote:
>I've had experience with debugging 80188 from a pod (ICE), that was
>better, but the freakin' POD would be difficult to get working
>sometimes: bad connections, bad Windows driver, sick Windows install, [...].
>
>This project, I chose a processor with built in debug capabilities
>(JTAG) and spent some real money and get an Abatron BDI2000 pod.  Then
>spent time learning about Insight.  GNU gdb I'm familiar with as I've
>run Linux for many years.
>
>I won't part with my JTAG!  I just love how it works, it so reliable and
>stable.  I've chained the JTAG lines of the two processors together and
>can debug them both with a single pod and two instances of Insight.  No
>thank you, I'll keep my JTAG!  It's too painfull to do it the "other
>way"!  :-)

I don't think I disagree with you here.  JTAG is certainly useful and a lot 
less cumbersome that an ICE pod.  Especially if the pod consists of a multi 
cm high tower that has to be soldered to a 144 pin QFP outline.  Been there 
done that.  It's just you seemed to imply you couldn't develop without 
JTAG.  Not wanting to or being more efficient with JTAG is another question 
entirely.

There are times I find a simple print much faster and just as 
illuminating.  That may be as much a matter of familiarity as any real 
productivity difference.  Certainly walking through the inner workings of a 
routine is much easier and faster with JTAG.

> >Of course there are situations where JTAG or a real ICE is very nearly
> >essential.  In fact I'm not yet convinced that JTAG is a complete
> >replacement for a proper ICE since I have yet to run into a situation on a
> >JTAG equipped micro that demanded the full capabilities of an ICE.

And this is where something else is needed.  I haven't seen any way to deal 
with timing issues with JTAG, for that the most effective way seems to be 
pin toggling.  Then there are those problems that you cannot stop the 
microprocessor since to do so will necessarily result in invalid results in 
the best case and blown hardware or worse in other cases.  There are a 
number of problems that the only effective way I've found to deal with is 
to provide a data log that is later downloaded to a PC for analysis at a 
safe or convenient point.

> >Serial downloads do work quite well and since JTAG takes up so many general
> >purpose I/O pins I can see why someone would want to dispense with it,
> >especially on the lower pin count devices.  A lot of products really don't
> >have room for a 144 pin package especially just to add a debugging 
> interface.
> >
> >
> >
>When I needed more I/O on the LPC2138 / LPC2106 board, I looked to the
>SPI bus.  There are three MAX3100 UARTs  and a NLSF595 LED driver on
>SPI0 of the LPC2106 processor.  SPI works really well.

A good choice, but there are those applications that can't deal with the 
time overhead.  There are others where Those In Charge (TM) are not willing 
to tolerate the extra piece cost of the expansion chip even if it might 
save them money overall by reducing the development effort and time.

>I do like the self-contained aspect of the LPC2000 parts, that is their
>best feature.

Absolutely one of their best features.

I'm not arguing against the use of JTAG, only that in some circumstances it 
either cannot handle the problem or that other circumstances may force you 
to work without it.

I am a little worried that the presence of JTAG has meant that there is no 
real ICE for the ARMs so that the most powerful tool in the development 
arsenal is going to be missing when a really intractable problem 
appears.  I expect ETM would cover most of the remaining territory but a 
lot of the new parts don't have that support and of course it takes away 
even more pins.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/