Lpc2000

John, 

> > > The Signum JTAGjet claims download speed in excess of 1 
> MByte/sec, 
> > > not 1Mbit/sec.
> > 
> > You can't get anywhere near that on ARM7TDMI-S parts which we are 
> > dicussing,
> 
> Comments below!
> 
> > so this claimed speed is irrelevant in this instance.
> 
> You made a factual error about the hardware capibility of 
> another product in the course of sneering the product. You 
> stated words to the effect "Not so jet after all".

No, I don't think I made that assumption.  I didn't sneer either--I just
said in this instance we've proven that the expensive JTAGjet is slower
than a $20 wiggler when downloading and flashing an LPC229x.  I've even
provided numbers to prove it.

> First ETM (Embedded Trace Macrocell) is fitted to all 
> LPC2xxxx ARM7TDMI-S parts and uses pins independently of JTAG 
> and so TCK. If LPC2xxxx parts are happy to support ETM 
> speeds, I don't see why the same parts cannot support very 
> high JTAG speeds. Why should one set of pins support very 
> high speeds and not another.

Try this link.  http://www.arm.com/support/faqip/3732.html.  Extracting
the relevent details, "If the RTCK output is not used, it is required
that TCK is running at a maximum of 1/6th the system clock frequency if
only 1 JTAG synchroniser is implemented in the system."  Although the
ETM will run quickly as it's driven from the core, JTAG will not run
quickly because without RTCK you can't send data at more than 1/6th the
system clock frequency.  For an LPC2k at 10MHz, that's 1.67MHz TCK.

> Second the JTAG hardware embedded in ARM7TDMI-S parts is not 
> part of the core hardware. It monitors the buses and bus 
> signals and is clocked independently of the core with the JTAG TCK.

Correct.

> Third the core hardware is hard hardware. Whether the ARM 
> core is labelled with S or not for synthesised has nothing to 
> do with the speed at which the independent JTAG hardware can 
> be clocked at. While I acknowledge non synthesised designed 
> cores have less risk attached to them in terms of using 
> proven hardware designs, there is no inherent reason why 
> synthesised cores cannot have their JTAGS clocked at well over 1Mhz.

Read the above.  I didn't say they could not.  I can achieve a 4MHz TCLK
on an ARM7TDMI-S.

> I am not an expert on the limiting issues of maximum JTAG TCK 
> clocking speeds, however I suspect if there are such issues 
> it is has to do with factors independent of the part, which 
> may be simply solved. For example using proper speed cabling 
> and including simple RC filters to reduce signal crossover at 
> high speeds near part pins.

No, you're completely wrong here.  The factors are part of the JTAG
design on the part, as the above link shows.

> > > From the Signum web site
> > > http://www.signum.com/Signum.htm "Actual speed 1.062 Mbyte/sec 
> > > tested with ARM Evaluator 7T board and 600 MHz Pentium 
> III PC with 
> > > USB 2.0 port. Faster PCs may yield faster downloads."
> > 
> > Yes, the Evaluator-7T is a hard core and TCK can be clocked at
> 10MHz in
> > this case (or greater in some cases).  However, not all ARM parts 
> > support this.
> 
> Hard core or not is not relevant. See above.

Yes, it certainly *is* relevant.  The ARM7TDMI is different from an
ARM7TDMI-S and the internal JTAG architecture *is* different.  ARM even
produce a document showing the differences.

> > > Since the JTAGjet uses USB 2.0 this is reasonable, provivded the 
> > > target device and connections can hold up.
> > 
> > USB 2.0 conformance does not imply a high speed device.  
> CrossConnect is
> > a USB 2.0 full speed device. Is the JTAGjet a full speed or high
> speed
> > device?  Or are you making the assumption that all USB 2.0 devices
> are
> > high speed and equating 2.0 devices to be inherently faster 
> than 1.1 
> > devices?  USB 1.1 full speed devices can support 1Mbyte/sec data
> rates
> > over USB so the statement "Since the JTAGjet uses USB 2.0 this is 
> > reasonable" holds no weight.
> 
> What are you trying to pull off here?  Of course it holds weight. 
> Since the specs mention capibility up to 480Mbits per second 
> then we can assume the JTAGjet advertises itself to the USB 
> bus as being able to support full USB 2.0 speed and not only 
> that, appears to claim capibility of processing the USB speed 
> offered from and to the without signalling bottlenecks, if 
> the part allows. Since I don't have the USB specs to hand I 
> do not know what the highest average speed that USB 2.0 is 
> capable of supporting from the PC side.

A USB 2.0 device can run at 12 or 480Mbps.  If you say "full USB 2.0
speed" then that means 12Mbps.  Even so, a full speed device should be
able to transfer data at well over 1MB/second, which is 8Mbps.

> > > The Signum JTAGjet also claims compatibility with all major ARM 
> > > debuggers and another version of the JTAGjet supports ETM.
> > 
> > ...your point?
> > 
> 
> Relevancy and fair representation.
> 
> If your product is used it will only work with your ARM IDE 
> (including debugger).

For now, yes.

> Signum claim the JTAGjet will work with 
> all major ARM debugger and compilers such as IAR, GNU, ARM 
> etc. Signum does not list your product as a major ARM product.

I wouldn't want it to.  We are not in the Signum market.

> ETM (Embedded Trace Macrocell) is fitted to all the LPC2xxx 
> products and so it is relevant for debugging. It does not use 
> the JTAG ports

Pardon?  The ETM connector does use JTAG signals and they are require
for debugging.  The ETM is for tracing.

> Some additional relevant points
> 
> Since JTAG is bi-directional, faster downloads mean fast uploads. 
> Fast uploads mean fast filling of data blocks at breakpoints, 
> which is the point Chris mentioned.  Developers examine 
> breakpoints more often than they download.

What does "examining a breakpoint" mean?  How much data do you need to
upload at a breakpoint for heaven's sake?

> Keeping code in RAM means more breakpoints become enabled 
> than the two breakpoints that are available when debugging 
> code in Flash (unless fancy tricks are used that reduces flash life).

I agree here.

> Even if all code will not fit in RAM, some of the code can be 
> copied from flash to RAM during startup to run from RAM. The 
> code running from RAM will also have the luxury of not being 
> limited to two breakpoints.

Correct.

> I really don't have time for this.

Sure you do.  Otherwise you wouldn't have responded.

-- Paul