Lpc2000

--- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@r...> wrote:
> 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".

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.

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.

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.

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.

> > 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.

> > 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.

> 
> > Leaving aside the issue of delays introduced by programming 
> > Flash, which many developers do not need to bother with 
> > during development if all their code fits into RAM, the 
> > claimed speed supports what many developers welcome and which 
> > was mentioned by Chris: rapid reading of data blocks at 
breakpoints.
> 
> We are dicussing speed on the LPC2000--which, by definition, people 
*do*
> need to worry about because many devices have limited RAM, no 
external
> bus, but lots of flash (like the 2148, for instance).  The claimed 
speed
> avantage of the JTAGjet is put to the test in this instance and is 
below
> even the lowly speed of a wiggler.  The original poster said his 
code
> did not fit in RAM and he needed to put in in flash--so the claimed
> speed advantage of the JTAGjet is worthless (in this instance).
> 

It is helpful if we stick to core issues. There is no monopoly on 
flash programming techniques, which are relatively simple. 
Here is one simple method of programming flash with JTAG that all 
JTAG debuggers can use

1. Download flash programming code to RAM
2. Download a portion of code to be programmed through JTAG to RAM
3. Execute code in RAM to program data previously downloaded to RAM 
to flash

Steps 1 and 2 are influenced by download speed
Step 3 is not influenced by download speed. Step 3 introduces a 
bottleneck that has more of a penalising effect on faster 
downloaders. Whatever flash programming method one device uses, so 
can the other.

> > 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). 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.

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

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.

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).

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.

I really don't have time for this. It does not earn me bread and 
butter. I am not a ARM or any other tools vendor or representative.

I have evaluated an LPC2xxxx part using a Wiggler clone with OCD 
Remote/Insight. I am working on projects with another non ARM part 
that uses a USB debugger. I know the value of being able to read back 
data quickly into a debugger at breakpoints and I know the value of 
being able to obtain trace information unobtrusively. I monitor the 
group to keep abreast of interesting developments that I may use in 
the future. I do not enjoy participating in negative debate.

John Heenan