This little project can be used to demonstrate the speed of the different JTAG hardwares. This doesn’t mean that you couldn't achieve even higher speeds in these hardware architectures. But it will serve as a sample project and it will help you to reconstruct the measurements of your own (if you have the different hardware). Insight was used to determine the transfer speed. At the end I will compare CrossWorks for ARM and YAGARTO.

All the measurements are done with downloading into RAM only.

The test was made with the following JTAG hardware:

• Parallel port device (wiggler clone)
• FTDI FT2232 based USB device
• J-Link USB device
• CrossConnect
• CrossConnect Lite
• CrossConnect Pro (only a prototype was available for testing)

I used a parallel port device and a FT2232 based device which were supported by OpenOCD.

The parallel port and the FT2232 based devices contain no software, only the hardware is different. But all FT2232 based devices use the same chip, therefore everything is the same here and the manufacturer was not specially named.

The J-Link is a proprietary device, I don't know what is inside,
therefore I could not name it, the same with the CrossConnect.

Some information about the software that was used:

• Insight from the YAGARTO package, Insight-6.8.50-20080308
• OpenOCD, r657
• J-Link GDB Server, V3.80c
• CrossWorks for ARM 1.7 Build 8

OpenOCD was used for the parallel port and FT2232 based devices. For the J-Link hardware the J-Link GDB Server is needed (J-Link howto).

CrossWorks for ARM comes with the driver for CrossConnect.

Example projects

str7jtagspeed for GCC

lpcjtagspeed for GCC

str7jtagspeed for CrossWorks for ARM

lpcjtagspeed for CrossWorks for ARM

Results YAGARTO

The speed results can fluctuate depending on the computer that is used. Therefore these results are only an order of magnitude (KB/sec = bits/sec / 8 / 1024) .

For the following test the STR7 USB-MSD board was used. For the OpenOCD the jtag_speed is set to 0, which produces a JTAG-Clock of 6 MHz.
Here are the results (load size 393628):

For the next test the LPC-L2294 development board with a 14.7456 MHz crystal was used. Here we had to use a JTAG-Clock less than 14.7456 MHz / 6. For the OpenOCD the jtag_speed was set to 3, which produced a JTAG-Clock of 1.5 MHz. For the J-Link I used 1.6 MHz. Here are the results (load size 393552):

The JTAG speed of the parallel port depends on the speed of your PC. For OpenOCD the jtag_speed is set to 0. The "fast" test was made with the following settings:

monitor arm7_9 fast_memory_access enable
monitor arm7_9 dcc_downloads enable
monitor verify_ircapture disable

The "x / FT2232" value is the standardized value referring to the ft2232 result.

You can calculate this value by using the bits/sec value divided by the bits/sec value from the ft2232 test. Example for J-Link: 106 / 21 = 5.04

Note: The results depend on the amount of data that was downloaded. I don't know why the result from Insight depends largely upon the load size. Normally performance measurements are the better the more data is loaded. But here the results are confusing, in case I use load size values greater than 384KB. In this case the bits/sec results decrease. Perhaps someone has an explanation for that?

Even the results from the FT2232 test with 6 and 1.5 MHz were confusing to me. I expected that a JTAG-Clock of 1.5 MHz would produce a speed of 6 MHz / 4.

Therefore I asked Dominic, the creator of OpenOCD, for an explanation:

"The USB latency is mostly the limiting factor, and not the JTAG clock rate. The OpenOCD must wait again and again for the results of the USB before it can send commands for the next data. Above all the FT2232 reaches the full 6 MHz probably only with very large scans - when debugging there are mostly less than 40 to 50 bits per scan, wherewith the full speed can't be reached."

Results CrossWorks for ARM

Now I am curious about the speed of CrossWorks, and make the same test here.The YAGARTO tests were made without taking into account the verifying speed. Therefore the CrossWorks test was made without considering the verifying too.

For the following test the STR7 USB-MSD board was used.
Here are the results (load size 393958):

For the FT2232 the JTAG-Divider must be set to 2. With a divider of 1 it produces download errors only.

For the next test the LPC-L2294 development board with a 14.7456 MHz crystal was used. Here we had to use a JTAG-Clock less than 14.7456 MHz / 6. Or use the RTCK feature if the CrossWorks Target support it. Here are the results
(load size 393978):

The FT2232 has no RTCK feature, therefore we must set the JTAG-Divider to 4. With a divider of 1 it produces download errors only.

YAGARTO / CrossWorks

Ok, now I will compare the speed from YAGARTO vs. CrossWorks for ARM. Both use the GCC compiler. Therefore the execution speed of the embedded application is not important here (this will be an other story).

The normal development process looks like this:

1. Editing the source
2. Compiling the source
3. Downloading the application to the target
4. Testing the application
5. In case of an error go back to 1

Now we will take a look at the download performances of the different targets. We will start with the STR7 USB-MSD (download into RAM):

And here the download performance for the LPC-L2294 (download into RAM):

Now you can decide what is the best for you.

The YAGARTO toolchain was created to have a cheap solution for the beginners. Because the software is free and you must pay for the JTAG hardware only.

For CrossWorks for ARM you'll need some bucks, but you'll get a good performance and a smooth workflow.

Do I need RTCK?

The CrossConnect hardware and the J-Link supports the RTCK feature. I asked Rowley why the RTCK feature is importand to them:

"The advantage is that when the core's clock is dropped to a lower frequency then you don't lose your JTAG connection. If you are running the core at 32kHz then you need a way to adapt to that. This isn't so much of a problem on the LPCs, but the SAM9 (for instance) comes out of reset at 32kHz and then the JTAG is really slow so RTCK is needed, or a way to change the JTAG frequency dynamically. We've built that into CrossWorks too."